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DATA PROCESSING SYSTEM 

The present invention concerns an electronic data 
processing system for the management of loans. 

A typical example of a loan that has to be managed is a 
Repayment Mortgage in which a loan is secured against 
property assets and repayments by the borrower typically 
comprise both interest due and an element of repayment 
of capital. 



Administering and managing Repayment Mortgages has become 
more complex with the advent of Offset Repayment 
Mortgages. An Offset Repayment Mortgage is a Repayment 
Mortgage where although borrower payments in excess of 
interest due still comprise an element of repaid 'capital 
some of these repaid capital amounts can be elected to 
be presented differently, thus requiring them to be held 
and treated differently by the electronic processing 
system used in the management of loans. 



*• 



Under an Offset Repayment Mortgage, payments by the 
borrower are either allocated as interest, capital, 
effectively reducing the loan's capital balance upon 
which interest is charged, or to a savings account. 



There may be more than one savings account and these 
typically might be called Holiday Account or School Fees 
Account etc. in economic reality all payments under any 
type of Repayment Mortgage that are not interest reduce 
the capital balance upon which loan interest accrues and 
thus the amounts allocated to the savings account do not 
accrue interest but instead are offset against the loan's 
capital balance on which interest is charged. However 
payments allocated to the or each saving account under 
an Offset Repayment Mortgage could alternatively be 
presented as not reducing the capital balance upon which 
interest accrues but instead- are increased over time by 
the mortgage rate of interest and this accumulated value 
is offset against the capital balance when determining 
the amount needed to redeem the mortgage. 

Currently available computer systems for the management 
of loans are relatively inflexible as a result of which 
the range of different loan types which can be 
administered, and therefore offered to the public, is 
severely restricted. 



An. object of the invention, at least in the preferred 
embodiment, is to provide a computer system for the 
management of loans having a novel database structure 
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which provides added flexibility permitting 
administration of a wider range of different loan 
arrangements than is possible with currently available 
systems . 

Another object of the invention/ at least in, the 
preferred embodiment, is to provide a computer system for- 
the management of loans having a novel user interface 
structure permitting a range of different loan 
arrangements to be set up with ease by relatively 
unskilled operators. 

In the preferred embodiment of the invention, the 
database structure includes one or more fields for 
storing, in relation to one or more loans, one or more 
variable index values which may be used for adjustment 
of the value of an asset or assets which may be offset 
against the amount of the loan. The preferred embodiment 
may accordingly make it possible to set up, in addition 
to simple repayment and offset mortgages, more complex 
mortgage arrangements. As an example of such a more 
complex loan arrangement, the computer system may be 
arranged to cause the value of an asset which is offset 
against a loan to be varied so as to track an external 
index, such as the FT-SE 100 index or the value of shares 
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in a selected company or a particular interest rate. 
This tracking may be achieved in the preferred embodiment 
by changing the value of the stored variable index value 
at intervals, for example daily, so that the stored value 
varies in accordance with changes in the external index, 
and "causing the computer system to perform processing 
operations- -which- vary - the. store-d" value of the asset on 
th£ basis of the varying stored variable index value. 

The changing of the value of the variable index may/ in 
an embodiment, be carried out manually. Preferably, 
however, a module is provided in the computer system for- 
effecting this adjustment automatically by reference to 
external data such as the FT-SE 100 index or the value 
of the relevant shares or a particular interest rate. 
The external data may, for example, be accessed via the 
internet . 

The preferred embodiment also includes a user interface 
for permitting the operator to set parameter values which 
determine the apportionment of repayments as between 
interest due, capital and the asset or assets to be 
offset against the loan. 
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The above combination of features of the preferred 

embodiment provides substantially improved flexibility 

compared to prior systems. This is so particularly where 

« 

the database structure includes a plurality of fields as 
referred to above for storing a plurality of respective 
different index*values , permitting the system to provide 
simultaneously a wide range of different loan 
arrangements. For example, causing different stored 
variable index values to track different external indices 
enables the offset asset values of different mortgages 
managed by the system to track respective different 
external indices and/or enables a single mortgage managed . 
by the system to be offset against the sum of a plurality 
of different assets each tracking a different external 
index. Loan arrangements in which the amount owing is 
offset against an asset or assets tracking an external 
index will be referred to herein as "Index Loans". 

A review module is preferably included for determining, 
at intervals, the net position, and this module is 
preferably operable to output a warning message in the 
event that a predetermined net position arises. 
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In order that the present invention may be more readily 
understood an embodiment thereof will now be described 
by way of example and with reference to the accompanying 
drawings, in which: 

Figure 1 is a block diagram of an overall view of a data 
•processing system in accordance with" the present 
invention ; 

Figure 2 is a block diagram of a server according to an 
embodiment of the present invention; 

Figure 3 is a block diagram of a terminal forming part 
of the data processing system shown in Figure 1; 

Figures 4A, 4B and 4C show examples of screens which in 
the present embodiment . are displayed on a user interface 
at a terminal; 

Figure 5 is a flow diagram of processing carried out in 
the system of Figure 1; and 



Figure 6 are block diagrams illustrating database 
structures involved in the data processing system shown 
in Figures 1 and 2 . 



The embodiment to be described is capable of managing a 
range of repayment loans including standard repayment 
mortgages, and more sophisticated variants of standard 
repayment mortgages. 

'The operation of standard repayment loans is well known. 
Thus an initial capital sum advanced to the borrower-is 
repaid over a period of years by regular payments which 
are used firstly to meet interest charges and secondly 
to make reductions in the initial capital sum. a 
relatively unskilled clerical worker can process the 
requirements of such loans with ease. 



Thus the main transactions under a standard repayment 
mortgage can be set out as follows :- 

Firstly, the lender makes a mortgage loan to a borrower. 
This is the initial Capital Balance Outstanding and also 
the initial Redemption Amount. The Capital Balance 
Outstanding is the amount of the loan at any time upon 
which interest accrues. The Redemption Amount is the sum 
necessary to be paid by the Borrower to the Lender at any 
time to discharge all and any remaining liability under 
the mortgage excluding any Redemption Penalties or 
Outstanding Interest. 
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Secondly the borrower at regular intervals pays interest 
based upon the Capital Balance Outstanding and the period 
since it was last paid. Borrower payments made in excess 
of the interest due are called Capital Payments and are 
used to repay part of the loan so that both the Capital 
♦ Balance Outstanding and the Redemption Amount are reduced 
—at each payment . ■ Clearly the Capital Balance Outstanding 
and Redemption Amount are always identical. The above 
steps are repeated over the duration of the loan until 
the Redemption Amount is' reduced to zero.' 

It will be appreciated that the lender may make further 
advances to the borrower before the Redemption Amount is 
reduced to zero so that the Capital Balance Outstanding 
and the Redemption Amount will be increased by the amount 
of the further advance. 

Although standard repayment mortgages are normally paid 
on a regular monthly basis it is of course possible for 
the borrower to make interest/capital payments on a 
regular and /or ad hoc basis. Finally the amount due from ' 
the borrower to the lender upon early redemption, in the 
absence of any other penalty charges is the Redemption 
Amount plus any outstanding interest due but not paid. 



t 



10 



15 



20 



9 

However it must be appreciated that any of the above 
procedures are relatively simple as any system dealing 
with such a mortgage is only concerned with the liability 
situation. 

As already described a more complex variant of the 
standard repayment loan or mortgage has recently -been 
introduced, this being the Offset Repayment Mortgage. 

The following is a simple example of an Offset Repayment ■ 
Mortgage as compared to a standard repayment mortgage. 

Consider a new £100,000 loan with interest due monthly 
in arrears at the rate of, say, 1% for the month. 

Standard Repayment Mortgage 

After the first month the accrued interest due is £1,000 
and assume the borrower makes a payment of £1,500. Under 
a Repayment Mortgage the capital balance would be reduced 
to £99,500 (although exactly when this affects the 
accrual of interest due does vary from lender to lender) . 
At this point, ignoring any redemption penalties, the 
amount needed to redeem the mortgage is clearly £99,50o". 
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Assume the next month's interest due is £995 and the 
borrower again pays £1,500. At this point, ignoring any 
redemption penalties, the amount needed to redeem the. 
mortgage is clearly £98,995. 

Offset Repaymen t Mort-.q ago 

Assume "the 4 - borrower wishes £150 of the monthly payments 
to be allocated to a Holiday Savings Account and £100 to 
a New car Savings Account. At the end of the first month 
" accrued interest is still £1,000 and so £250 is allocated 
to reduce the capital balance after the savings account 
contributions have been made; At this point, ignoring. • 
any redemption penalties, the amount needed to redeem the 
mortgage is £99,500 as this is £99,750 less £150 less 
£100 in the two 'savings' accounts. 

The next month's interest due would be calculated as 
£997.5 but the two savings accounts would have interest 
at 1% added to them (£1.5 and £1 respectively), when the 
borrower now makes the ' second payment of £1,500 it is 
allocated as £997.50 interest, £250 in total to the 
savings accounts and the remaining £252.50 to reduce the 
capital balance. Thus the capital balance . g ^ 
£99,497.5 and the savings accounts are worth £301.5 and 
£201. At this point, ignoring any redemption penalties, 



the amount needed to redeem the mortgage is £98 , 995 as 
this is £99,497.5 less £301.5 less £201. 

When any payments allocated to the or each savings 
account are increased at exactly the mortgage interest 
rate it can be seen that an Offset Repayment, Mortgage is 
economically identical to a normal Repayment Mortgage.- 

It will be appreciated that under the alternative method 
of presenting an Offset Repayment Mortgage the amounts 
in the two savings accounts are offset against the 
capital balance when determining the amount of mortgage 
interest due and the savings account do not increase or 
change in value. The overall result is, of course, 
economically identical at all times. 

However this type of mortgage is more difficult to manage 
than the standard repayment scheme if the client (or the 
lender) wants a rapid update of the loan situation. The 
added complexity is brought about by the presentation of 
the Redemption Amounts as Liabilities less Assets. 

However, there is no logical reason why the value of such 
savings accounts has to be linked to the mortgage's 
interest rate. Alternatively they can be linked to any 
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index of prices (Price Index). m addition, each 
separate savings account could also be linked to more 
than one Price Index and each savings account might be 
linked to different Price Indices - although this would 
clearly break the economic equality referred to above 
unless it so happened that the Price Index Hinks are all 
always exactly increased by the" mortgage interest rate. 



As already noted, for ease of reference a loan whose 
repayments can be allocated between interest, capital and 
savings accounts as described above but with the 
flexibility that each savings account can be linked to 
one or more Price Indices is termed an Index Loan herein, 
with the capital balance referred to above called 
Liabilities and the value of the savings accounts called 



Assets , 



Index Loans thus have a similar basis to the Offset 
Repayment Mortgages just discussed but have the 
additional complication that the repayment of the Index 
Loan is selectively linked to one or more Price Indices 
so that the Capital Balance Outstanding remains the same 
until either redemption occurs or further advances are 
made or repayments of capital are made. There is thus 
an increasing exposure to at least one Price Index 
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generated by the positive payments made by the borrower. 
However, whilst with a standard repayment loan it is easy 
to predict funding requirements even given variable 
interest rates, as these are always known in advance, 
this is not possible with an Index Loan for reasons which 
will become apparent. , 

T f hus one aspect of the present invention concerns an 
electronic data processing system capable of managing not 
only a standard Repayment Mortgage but also of managing 
Offset Repayment Mortgages and Index Loans and the 
problems associated with dealing with a wide number of 
mortgage variants and if it is wished to track and manage 
the Net Position (either the value of Assets less 
Liabilities or Liabilities less Assets). 

The daily or even more frequency management of such Net 
Positions could prove to be both onerous and difficult, 
particularly for relatively unskilled administrative 
staff. 

It has long been appreciated that the performance of the 
stock markets (as one example of a basis for a Price 
Index) has historically been better than interest based 
assets such as deposits or bonds. Thus meeting a 



Liability by utilising repayments partly or wholly linked 
to a Price Index based on share prices is likely to give 
long term benefits to borrowers. However, creating 
exposure to such a Price Index, or* multiple Price 
Indices, on a regular basis, as required for Index Loans, 
would raise a complex set of problems in a market such 
as the mortgage market where the Net Position has always 
,to be taken into account. For example in the mortgage 
market lenders issue in the UK some 1.5 million mortgages 
a year with a total value of approximately 
£145,000,000,000. Thus the handling on such a scale of 
-Net Liabilities linked to Price index movements which- are .. 
potentially volatile can cause major problems to 
administrators and managing one's Net Position would also 
be beyond the capability of all but the most financially 
sophisticated borrowers. in particular it is important 
not only that clerical staff have available to them a 
simple way of entering the parameters which control the 
very wide range of loan types but that the clerical staff 
administrating such Index Loans can readily compare the 
necessary balance between Liabilities and Assets and also 
make alterations to the investment profiles such as 
changes of Price Index. 
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As already stated with repayment loans of which a 
mortgage is only one example, it is simple to calculate 
future requirements as interest rates are known in 
advance so that if there* is an interest rate change it 
is simple to make the necessary adjustments either to the 
term of the loan or to the necessary increased repayments 
required to meet increased interest changes or reduced 
payments to meet interest rate reductions. 

However, Price Index volatility is such that in order to 
set the terms of a new Index Loan it is necessary for 
assumptions to be made with regard to future. Price Index 
movements for the Price Index links of Price Index 
exposure created by future payments made in respect of 
the index Loan in order to try to ensure that the 
Liabilities are likely to be met at the end of the 
proposed term of the loan. it will be appreciated that 
as forecasting of such Price Index movements is by no 
means an accurate science it is also important to be able 
to respond appropriately to the history of the movements 
of the Price Index used during any period of the Index 
loan if the Price Index changes have been either 
favourable or unfavourable. Once again it has to be 
emphasised that it is not possible for a normal worker 
to be able to respond in such a manner without a new 
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dedicated computer system. 



As will become apparent the effect of the linkage with 
the or each Price Index can be considered as either 
affecting the interest payable or the Redemption Amount 
or a combination of both. The resulting overall effect 
" will be the same, but because of the- additional choice 
factor the management of the Net Liability situation 
remains very complex, in particular, the effect of the 
linkage of regular payments to at "least one Price Tndex 
means that due to the volatility involved it is very 
difficult for both the lender ■ and the borrower - to 
calculate at any one instant not just the current Net 
Liability situation but also to try and estimate the 
progress of the Net Liability in the future. The present 
invention is also concerned with providing a solution to 
this problem. 

Referring now to Figure 1 of the accompanying drawings 
this shows an electronic management system in accordance 
with the present invention comprising a main server 1. 
The main server 1 is connected by links 11 to client 
terminals 10 x , ... I0 n via a network N which can be the 
PSTN. Naturally a range of known types of local networks 
can be used. The main server 1 also has local input 



terminals 10 through which requisite data can be entered 
for storage in the databases to be described. 



Referring now to Figure 2 of the accompanying drawings 
this shows the main structure elements of the main server 
1 shown in Figure 1. The server 1 comprises a processor 
12, a main memory 13 and a random access memory 14.- The 
main memory 13 containing a program defining a database 
structure having storage areas DB1 to DB20 for storing 
an equivalent number of database files which will be 
described in greater detail hereinafter. Also provided 
...in. the. program, are. modules for. performing a plurality of 
processing routines Rl to R12. The main memory may 
comprise conventional mass storage means such as hard 
discs. The server 1 also includes a display 15 which is 
optional as the important displays will be those seen by 
users of the system at, for example, terminals 10, ... 
10„. These displays are carried out via the user 
interface routine R12. The server includes input devices 
16 which can comprise one or more keypads, interfaces for 
receiving inputs from one or more other networks and a 
reader such as a CDRom disc drive for receiving data from 
an appropriate storage medium. Finally the server 
includes the appropriate interface circuit 17 by means 
of which it can communicate with the Network N. 
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Turning now to the terminal 10 shown in Figure 3 this has 
a network interface 18 for enabling communication with 
the network N, a central processing unit 19, a display 
20, at least one input device in the form of a key pad 
21 and main and secondary memories 22 and 23. The main 
memory 22 includes storage areas for storing a plurality 
of standard routines usBd by a clerical worker to call 
up appropriate data from the main server so that a user 
can display a plurality of user interface screens, 
certain of which will be described hereinafter, for 
entering and displaying data so that the situation of 
any -borrower can -be displayed. Naturally the terminal . 
can be linked to a printer or other hard copy device. 

The system shown in Figures 1 and 2 is particularly 
suited to the management of not only standard repayment 
mortgages but the other types of mortgage already 
discussed. 

There will now be given a more detailed description of 
the databases DB1 to DB20. As the present embodiment is 
for the management of a range of loans and mortgages not 
all of these databases are essential. As will be 
apparent from the following description many of the 
database files are for user input and are not system 



specific. The organisation of some of the more important 
databases are illustrated in Figure 6 of the accompanying 
drawings . 

Thus database DB1 comprises storage areas for storing a 
Personal Detail file in response to user input. Thus 
this -database stores -the necessary personal details of- 
each borrower whose Net Liability position is being 
managed. The data stored in this database is input by 
the user via one of the input devices 21. The second 
database DB2 is optional and comprises storage areas for 
• storing a Third Party Detail, file which includes relevant . 
third party details such as those relating to estate 
agents or solicitors associated with the Liability. 
Again this data is input by the user. Database DB3 is 
a storage area which stores a Product file holding data 
which represents rules which govern each loan as these 
of course can be varied, again at the user's choice. 
Thus a particular set of rules will define a product as 
defined by a user. However the most important product 
rules can be summarised as follows: 

1) Interest calculation method. 



2 ) Redemption penalties . 



) Terms of any special interest rate details. 



These product rules are of course applicable to all the 
types of mortgages which have been discussed. 

Database DB4 is again a storage area for storing an 
Interest Rate file input by a" user and representing the" 
interest rates payable on each loan, the dates over which 
the interest rates were payable on each loan and the date 
From which the interest rates were applicable. "Once 
again this data is user specific and applicable to all 
loans and mortgages. 

Database DB5 is shown in Figure 6 and is a storage area 
for storing a Payment Allocation file which holds data 
relating to the allocation of a payment made by a 
borrower between Capital, Interest and to one or more 
Price indices if the mortgage or loan being managed is 
an Index Loan. This data is initially user input but is 
also involved in routine R8 shown in Figure 2 and which 
will be described hereinafter. Database DB5 acts as a 
control means which enables a wide range of parameters 
to be applied to the manner in which detailed processing 
is carried out for individual loans. 
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As can be seen from the drawing representing database DBS 
this database has six columns 500, 501, 502, 503, 504 and 
505 respectively named in this figure "LOANREF" , " START 
DATE", "END DATE", "CATEGORIES", "PRIORITY" # an d 
"ALLOCATION". Naturally, the actual database does not 
have columns named in this manner as the .data items will 
be stored in appropriate- address locations but the 
columns are ^ named in the figure as an aid to 
understanding. 
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The Loanref column 500 merely stores data identifying 
individual, index Loans. The Start Date column .501 Holds 
data identifying the start dates from which subsequent 
data in the database will determine the manner in which 
payments for a particular Index Loan will be allocated. 

The End Data column 502 is optional and if present holds 
data defining the end date of the particular set of 
allocation parameters. The Categories column 503 stores 
the three main categories between which each payment to 
a particular Liability, such as Index Loan xxxl, is 
allocated. These categories are Interest, Capital and 
Index. Column 504 stores data determining the priority 
which is given to each of these categories so that when 
a payment is made the category of highest priority, 



namely the Category called, in this example, Interest, 
will have the payment allocated to it in preference to 
any category of lower priority. with regard to Loanref 
xxxl payment of the interest has the highest priority 1, 
allocation to a Price Index or Indices has the next 
highest priority, 2, and repayment of capital has the 
lowest priority 3. These priorities are purely at the 
discretion t of a user but in this example it has been 
assumed that a user will naturally wish for all 
Outstanding Interest to be met before any allocation is 
made to another category. 



Thus the data item in the Allocation column 505 indicates 
that 100% of the Outstanding Interest is to be paid 
provided that the amount of the payment is sufficient. 
It is thus only after this payment has been made that 
other allocations are carried out. As can be seen the 
manner in which payments are allocated can be expressed 
in alternative ways, for example either as a fixed sum 
or as a percentage. Thus with regard to Loanref xxxl the 
data item in Allocation column 505 indicates that if the 
payment is sufficient £20 is to be allocated to the Price 
Index or Indices relevant to Loanref xxxl after the 
Outstanding Interest has been paid. Once this payment 
has been allocated then the third data item in column 505 
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shows that 100% of the unallocated remainder of the 
payment is to be allocated to the repayment of Capital. 
Naturally, it is entirely possible that the remainder 



will be zero. * 



As can be appreciated the resulting system is extremely 
flexible and completely under the control of the user via 
« the user interface routine 12. Thus the second Index 
Loan (Loanref xxx2) has the same priority given to 
Interest but has two ' equal priorities (2) to the 
allocation of the remainder of the payment. 

Naturally the system will also include routines to be 
followed if a payment is insufficient to cover all items 
of a particular priority. Once again such routines will 
be at the discretion of the user of the system. 

In a variant of the present embodiment also discussed 
with respect to Figure 4C, database DBS can also have a 
category representing penalty interest. Once again the 
user by means of an appropriate interface can set the 
priority for payment of penalty interest if any is due. 
In this case the database may store four priorities 1, 
2, 3 and 4. 
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Database DB6 is also shown in Figure 6 and is a storage 
area for storing a Price Index Links file which holds 
details of each Price Index which can be associated with 
a Liability together with the transaction type and 
relevant dates. It will be appreciated that for each 
Liability there will be a number of transactions which 
can be carried out such as normal payments , ad hoc 
payments , withdrawals etc. These different transactions 
are given the generic term transaction types. Once again 
the initial data is user input. The data stored in 
database DB6 is used in routine R9 as will be described 
hereinafter. 

Database DB7 is a storage area which stores in response 
to user input a Price Index Prices file which holds the 
actual prices of the or each relevant Price Index and the 
dates at which those prices applied. This data is also 
user input. The data input can be carried out manually 
or automatically from external sources such as the 
Internet or third party data providers. 

Database DB8 is a storage area for storing a Review Basis 
file in response to user input. This file holds the 
assumptions of Price Index movement under which the 
initial terms of the loan agreement were set as well as 



alterations to these assumptions made during the term of 
the loan. Thus the data held in this database can 
comprise: 



1) 



The outstanding term at the end of which the 
objective is that the Net Liability is less than or 
equal to Sero. 



2) The frequency of future Payments that will be 
exposed to a Price Index. 

3) The exposure amount of Payments associated with 
each Liability to a selected Price Index or Price 
Indices. 

4) The assumption of future Price Index movements. 

5) The current Net Liability. 

It has to be emphasised that as the system is dealing 
with volatile Price Indices in order to even start an 
Index Loan an assumption has to be made as to the 
possible movements of the or each Price Index to which 
an Index Loan is linked. 



Database DB9 is a storage area for storing a Price Index 
exposure file which stores in accordance with exposure 
rules set by a user the dates during which specified 
amounts are allocated to a Price Index. The basic data 
is user input and is utilised in routine R9 to be 
described hereinafter. For all transaction types there 
will be for' each Price Index link in database DB6 the 
amount or % of the transaction exposed to that particular 
Price Index. The allocations must sum to 100% for each 
transaction type. Also stored is the gearing, if any, 
which is to be applied in exposing a transaction amount 
to a Price Index and the minimum value. It will be seen 
that, as shown in database DB6 for Loanref xxxl, 
transaction type TT1 has links to three Price Indices 
(PI1, PI3, PI6) so that the allocation, gearing and 
minimum value data items in respect of these transaction 
types each have three entries. Once again this 
arrangement allows great flexibility to a user. 

Database DB10 is a storage area for storing a Borrowings 
Transaction File representing the amounts of borrowings 
or loans and the dates when such borrowings or loans were 
made to each borrower. Such borrowing or loan is held 
under a Liability that has a unique reference code 
associated with it as is shown for example in databases 
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DB5, DB6 and DB9 . 



Database DB11 is for storing data relating to regular 
payments by the borrower and involves both user input and 
5 routine R8. 



Database DB12 is a storage area for storing an accrued 
interest file, the Accrued Interest bein ? the interest 
which has accrued on each Liability and includes penalty 
interest (if any) and the relevant dates. This file is 
used in routine R2 to be described hereinafter. 

Database DB13 is a storage area for storing data relating 
to Paid Interest on each Liability which also includes 
the amount and date of such Payments and is used in 
routine R2 to be described hereinafter. 



Database DB14 is a storage area for storing transaction 
details including the transaction amounts, dates and type 
of transaction in response to user input and also for use 
in routine 3 and in routine 10 which will be described 
hereinafter. Data can also be stored in this file from 
an external source such as a bank into which payments 
have been made. Thus such payments can be entered via 
25 BACS. 



« 
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Database DB15 is a storage area for storing a Price Index 
Transactions file comprising data representing each Price 
Index transaction for each Liability being handled by the 
system including the unit amount of the transaction, the 
date of the transaction and the Price Index involved. 
This data is used in routines R3 and R9. The term "unit 
amount" will be defined in the description of routine 3. 

i 

Database DB16 is a storage area for storing a Corporate 
Transaction file. The presence of this database is 
optional as its contents represent, for example, 
commission payments to third parties and the dates of 
such payments. This data is user specific and is used 
in routine R7 to be described hereinafter. 

Database DB17 is a storage area for storing a Net 
Liability file the contents of which represents the Net 
Liability of each Liability managed by the system. The 
contents of this file are used in routines 1, 4 and 5 to 
be described hereinafter. 

Databases DB18, DB19 and DB20 are storage areas for 
storing a respective letter file, standard internal 
report file and a client statement file. Databases DB18 
and DB20 have user input and all three files are used in 



routine Rll to be described hereinafter. 



It will be appreciated that it is possible to organise 
the databases just described in other ways by either 
amalgamation or subdivision. 

* 

For example databases 11 and 14 could be amalgamated. 
Additionally it is only for convenience that database 
DB17 exists as this value can readily be generated on 
demand for display from data already present in databases 
DB1, DB14 and DB15. 



As will be described the data processing system of 
Figures 1 and 2 carries out in response to stored 
routines seven main process steps in response to data 
stored in the databases shown in Figure 2: 

These processing steps are: 



Calculating Accrued Interest. 

Collecting Payments (automated for regular payments 
and manual for ad hoc payment) and allocating them 
as various types of transaction and making payments 
to the borrower. 



Generating transactions between the lender and 
various third parties. These would include 
payments to funding sources, fees to packagers, 
commission to brokers etc. Under an Index Loan 
there are, at the lender's discretion, some 
possible additional payments, for example a 
commission based upon the value of the Assets. 

Switching the Price Index links either of current 
Price Index exposure or that which will be created 
by future Payments. 

Carrying out Reviews. This is the process of 
reviewing how the value of the Net Liability is 
proceeding against plan and whether any change up 
or down to the regular payment level is required. 
This is specific to an Index Loan. The. purpose of 
Reviews is to help ensure that the Price Index 
exposure gained by expected future Payments is set 
to the "best" level. in this case best means that 
according to the assumptions made the currently 
proposed future Price Index exposure amounts are 
within the tolerance levels of the required amount 
that the Review process calculates. A small part 
of this process is taken up with the interest 
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element of any regular payments made by the 
borrower. This occurs with all loans and is a 
matter of comparing cumulative Interest Paid to 
cumulative Accrued Interest. The main part of the 
Review process is thus taken up with determining 
what the theoretically required Price Index 
exposure per regular payment is, on the current set 
of assumptions. A review and possible change of 
these assumptions is also part of the Review 
process and to compare the result to the current 
exposure amount and the acceptable tolerance 
between the two as set out as part of the Review 
assumptions. Calculating the theoretical Price 
Index exposure amount requires the calculation of 
an accumulation factor which will be defined 
hereinafter and which requires a future Price Index 
growth assumption. The Review process may cause 
this assumption to be revised from time to time. 
Deducting the current value of Assets from the 
current Total Borrowings equals the Net Liability 
and the amount needed currently to redeem the Index 
Loan (excluding any Outstanding Interest and/or 
Redemption Penalties). The projected future value 
of the current value of Assets plus the accumulated 
value of future proposed Price Index exposure 
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amounts must between them at least equal the 
current Liabilities if the Index Loan is to be 
repaid by the projection date. 

6. Maintaining a database of Price Index movements 

i 

7. Carrying out redemption checks. when the Net 
Liability is first less than or equal to zero the 
system will create a warning flag and possibly 
automated Index Loans redemption processing. 

There will now be given a description of routines Rl to 
Rll which are invoked to carry out the above main process 
steps . 

Thus routine Rl is used to calculate Total Borrowings and 
is carried out whenever routines R2, R6, and R8 are to 
be run and when those items in routine Rll involve or 
require an up-to-date Total Borrowings number or a User 
requires such, for example upon a request for this 
information submitted by a client. 

The routine involves summing all transactions' for a 
particular mortgage or loan code that appears in database 
DB10 (which means they are Borrowing transactions by 
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definition) and summing all transactions of the Repaid 

Borrowing type (whether such transactions arose from Ad 

Hoc Payments or Regular Mortgage Payments) for the same 

t 

mortgage or loan that appear in database DB14 in order 
to calculate the Total Borrowings at the calculation 
date . * 

The result, and calculation date, is sent to database 
DB17. This routine is similar to Sll in Figure 5. 

Note that Repaid Borrowing transactions in database DB14 
are held as opposite sign to the Borrowing transactions . 
in database DB10. 



Routine R2 determines the Accrued Interest for a 
particular Index Loan since the routine was last run. 
It will be necessary to subdivide this period if the 
interest accrual rate and/or the Total Borrowings upon 
which interest accrues changed during the period. The 
routine will determine such sub-periods using the rules 
of DB3 and the data in database DB4 and database DB10, 
collecting the appropriate interest rate(s) from database 
DB4 and applying them according to the rules of database 
DB3 to the applicable Total Borrowing collected from 
25 database DB17 for the relevant sub-period. 
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The result for each sub-period , and the sub-period's 
calculation date is sent to database DB12. 

Routine R2 is carried out according to the user defined 
product rules stored in database DB3 as to when changes 
to Total Borrowing f af fects the accrual of interest due 
from the borrower. Routine R2 is also required whenever 
routine R3 is to be run and the payment processed by it 
is to include an element for database DB13. Additionally 
routine R2 is required when routine R6 is to be run or 
when a User requires the information. 

Routine R3 is carried out either when a User instructs 
the system that a Payment (Regular Mortgage Payment or 
Ad Hoc Payment) has been received or that a Positive 
Advance is to be made or when the system has been 
scheduled that a Regular Mortgage Payment is due. In 
this case it is assumed that if such a scheduled due 
payment does not occur then routine RIO will pick this 
up and create the necessary opposite payment 
transaction (s) to neutralise the results of this routine. 
It is alternatively possible to set the system so that 
this routine is only activated for scheduled due payments 
once routine 10 has confirmed their receipt. 



The routine involves allocating any Payments made or 
falling due since the last time it was run between 
Interest (to become Paid Interest), Capital (Repaid 
Borrowing) and Index (to contribute to Price Index Value) 
according to the rules contained in database DB3. For 
example if Accrued Interest exceeds Paid Interest does 
any particular type of payment have to have any specific 
allocation that would override the normal allocation 
rules of database DB5. The rules in database DB3 may 
require data from databases DB12 and DB13 to be summed 
as part of the routine as already noted. Any Index 
amounts will be converted by the routine into units of 
specific Price Indices according to the relevant Price 
Index links that apply from database DB6 and Price Index 
exposure rules of database DB9, dividing the result by 
the relevant Price Index price from database DB7 in order 
to arrive at the Unit Amount. 

For Positive Advances the routine will execute the 
payment according to User input, either to the client by 
cheque or direct via the banking system and update 
database DB14 with this information or apply it as a 
Repaid Borrowing and update database DB15 with this 
information. This updating will comprise a negative unit 
transaction for one or more Prices Indices where the sum 
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of each unit transaction when each is first multiplied 
by the relevant price of the Price Index equals the 
payment amount. 

-* 

The Interest result, and calculation date, are sent to 
database DB13. 

The Interest and Capital results', and calculation da^te, 
are sent to database DB14. 

The Price Index unit amount results, and calculation 
date, are sent to database DB15; 

Routine R4 is carried out when routines R6 to R8 are to 
be run. It also may be used in routines R7, R9 and Rll 
or at the request of the User. 

The routine sums all unit transactions in database DB15 
separately for each Price Index, multiplies each such sum 
by the price of the relevant Price Index for the 
calculation date from database DB7 and sums the results. 

The result, and calculation date, is sent to database 
DB17 with opposite sign to that with which Total 
Borrowings are sent to database DB17 under routine Rl . 



Routine R5 is used to calculate Liabilities other than 
Total Borrowing and is carried out if routine R6 is to 
be * rUn ° r accordin 9 to a User defined schedule or rules. 

Database DB17 will already contain Total Borrowings as 
a result of routine Rl and Price Index Value from routine 
R4 as at the date this routine is working to . This 
routine calculates final items that routine R6 will 
require, namely any Redemption Penalties and any 
Outstanding Interest. 

Redemption Penalties are calculated by the routine based- 
upon the rules in database DB3 and are simply those 
amounts defined in the product code that apply at any 
given date to the Borrowings data from database DB17 if 
Total Borrowings are to be repaid in part or in whole. 

Outstanding Interest is calculated as the Accrued 
Interest less Paid Interest (summed from databases DB12 
and 13 respectively to the same date this routine is 
using and in accordance with the rules in database DB3 
if these apply) . 

The results, and calculation date, is sent to update 
database DB17 . 
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Routine R6 is carried out according to a User defined 
schedule or rules, or upon User request. 



The routine simply sums the data held in database DB17 
for the calculation date in order to determine a current 
Net Liability amount which is Total Borrowings less Price 
index Value plus Outstanding Interest plus Redemption 
Penalties . 

The routine can include a flag/ and/or indicator message 
regarding the relative size of the Net Liability and/or 
some form of automatic processing rules under which the 
Price index Value is utilised to repay Total Borrowings 
and any Outstanding Interest and Redemption Penalties 
thus creating a Repaid Borrowing transaction in database 
DB14 and a Positive Advance transaction in database DB14 
and database DB15 (and possibly a Paid Interest 
transaction in database DB13 and possibly a Redemption 
Penalty transaction in database DB14). 

Routine R7 is carried out according to a User defined 
schedule or rules, or upon User request and calculates 
sums for payment to various external parties such as 
commission to brokers or payments of interest to the 
funding source(s) of the mortgage or loan and executes 
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the payment process. For example this can be done on 
production of a cheque or direct credit via banking 
systems . 

The calculation rules and fee bases will be determined 
by data held in databases DB2 and DB3 and the sums upon 
which" such fees are applied could include Total or- 
further Borrowings from database DB10, Regular Mortgage 
and Ad Hoc Payments from database DB14 and Price Index 
Value from database DB7 and database DB14. 

The result, and calculation date, is sent to database 
DB16. 

Routine R8 is carried out according to a User defined 
schedule or rules, or upon User request and determines, 
according to various User defined rules and calculation 
methods from database DBS, what Regular Mortgage Payment 
will, upon various assumptions such as future average 
Price Index movement rates, be necessary in order that 
at some future defined date Net Liabilities will equal 
a specified amount, allowing for current Total Borrowings 
and Price Index Value (database DB17) as well as any 
current Outstanding Interest (databases DB12 and DB13), 
current Payment Allocation (database DB5), Price Index 
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Exposure (database DB9) and relevant Product Rules 
(database DB3) . 



Future Price Index assumptions may be determined all or 
in part by calculation of historic interest rates and/or 
Price Index price movements so that data will need 
collecting from databases DB4 and OB 7 and such historic 
rates calculated according to User defined rules, and 
applied to those Price Indices that are relevant 
(database DB6) . 

The routine's final result- is based upon the 

determination of whether, upon the basis of this interim 
result and various User defined tolerances and rules 
relative to the current Regular Mortgage Payment 
(database DB11), the Regular Mortgage Payment amount 
and/or allocation between Interest, Capital and Index 
needs to change and the effective date of such change. 
The routine will also involve the triggering of client 
correspondence regarding these changes if a change to the 
payment amount and/or allocation is the final result. 

The payment amount result, and calculation date, is sent 
to database DB11, the payment allocation and calculation 
date is sent to database DB5. 
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It will be appreciated that in the present embodiment 
Payments not allocated as Interest can either be used to 
repay part of the Index Loan so that both the Capital 
Balance Outstanding and the Redemption Amount are reduced 
by a known and fixed amount and/or can be elected to be 
used to reduce the Redemption Amount but not the Capital 
Balance Outstanding by an amount equal to the payment • 
allocation (Index) multiplied by a Price Index factor as 
will be described hereinafter. This reduction of the 
Redemption Amount, if selected, is achieved by reducing 
the Redemption Amount with an amount equal to Index 
multiplied -by the movement of one or more Price Indices, 
over the period from when the payment was made. Thus if 
the price movement is a 5% rise the relevant amount will 
15 have to be multiplied by 105%. it will be appreciated 

that the data processing system can also calculate the 
equivalent interest rate at any time under a standard 
repayment mortgage that would have produced the same 
Redemption Amount as generated by an Index Repayment 
20 Mortgage. 

It will be appreciated that as already described each 
Index Loan has to have certain basic parameters defined 
and the choice of these parameters define what is known 
25 as the Product type. For any borrower the user will 
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select the Product type and then input those details 
specific to that borrower such as personal information, 
loan amount and planned term. Thus the screen of Figure 
4A is directed to setting the product types in order to 
maximise new business processing efficiency as there is 
potentially a very wide range of Product types. Thus 
once a Product type has been set in database 3 a clerical 
worker need only access the Product type, match the 
details of an individual borrower and have readily 
available the relevant figures such as the repayment rate 
required to meet the potential Liability. Figure 4A 
• shows the screen by means of which Product types are set . - 
Thus window 100, in this embodiment, has seven sections 
101 to 107 respectively labelled "Interest Rate", 
"Payment Target", "Allocation", "Fund Investment", 
"Commission", "Penalty interest" and "Redemption 
Penalty". As shown at present, each of these sections 
consists of a drop-down menu so that the user can select 
from a plurality of choices other than those shown in the 
actual sections. 

Each different item in each drop down menu associated 
with the fields or sections 101 to 107 has associated 
with it a set of parameters which control the way in 
which the loan is managed and define the type and loan 



arrangement. Thus, different loan "products" may utilise 
different combinations of items from these drop down 
menus and/or different values for the associated 
parameters. Hence, in order to set up a particular loan 
arrangement, the user chooses a combination of items from 
the drop down menus of the sections or fields 101 to 107. 
If, to meet the particular requirements of a particular 
borrower, it is necessary to adjust the parameters 
associated with the selected items, this is achieved by 
navigating; by pointing and clicking operations, from the 
selected item to a user interface having fields for 
entering- values for the relevant parameters. - 



Thus, for example, field 102 in Figure 4A is for defining 
the way in which repayments made by the borrower will be 
applied as, for example, between capital, interest and 
an asset whose value is tracked by a stored index. 
Figure 4C shows the user interface associated with field 
102 in the current embodiment and as described elsewhere 
this user interface is arranged for entering values into 
database DB5 shown in Figure 6 . As can be seen in Figure 
4C, different payment target arrangements can be brought 
into effect at different dates utilising the fields 111 
which are so arranged that each time a new date is 
entered a new set of fields 112 and 113 is displayed for 
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entry of corresponding parameter values which will then 
be applied to payments made on and after the new date. 



More particularly Routine R12 generates the screen of 
Figure 4C and it is this screen which enables a user to 
enter the payment target parameters into database DB5. 
Thus the window shown at 111 display dates corresponding 
to column 501 of database DB5 . The column marked 112 
enables the user to add the selected categories 
corresponding to column 504 of database DB5 whilst column 
113 lists the categories to which a payment can be 
allocated, namely Interest, Capital :, Equity (Index) and 
in this variant Penalty Interest. Finally the columns 
enable the user to enter the data corresponding to 
whether these allocations are expressed as sums or 
percentages, corresponding to allocation column 505 of 
database DB5 . 

The other fields 101 and 103 to 107 shown in Figure 4A 
similarly have associated with them user interfaces for 
entering the values of the parameters defined by the 
items in the drop down menus. Thus, the user interface 
(not shown) associated with field 101 is for defining 
interest rates. The user interface associated with field 
103 is for defining additional allocations such as 



bonuses. The user interface associated with field 104 

is for selecting an external index which is to be tracked 

by a stored index value. The user interfaces associated 
i 

with fields 105, 106 and 107 are, as shown in the 
drawing, respectively for defining commission, penalty 
interest and redemption penalties. 

This set of user interfaces constitutes a user interface 

t 

structure which, together with the corresponding database 
structures, provides a highly flexible system for loan 
management in which it is very easy to set up a wide 
variety of different loan arrangements . There may be a 
set of standard loan arrangements or products defined by 
the system and/or bespoke loan arrangements may be 
created for individual borrowers as needed. Such bespoke 
arrangements can be created either by taking one of the 
standard products and modifying its defining parameters 
as necessary utilising the above described user interface 
structure or alternatively a new product can be set up 
by creating new items on the drop down menus shown in 
Figure 4A and defining values for the sets of parameters 
associated with those new items. 

Turning now to Figure 4B, this shows an example of a 
screen when a user requires to know the Net Liability 
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position of a particular borrower. 



As can be seen, the screen has a central window 110 
called up by the user which displays the Net Liability 
balance as calculated by the computer system of Figures 
l'and 2. Thus the additional Borrowing is accessed from 
database l(f," the Outstanding Interest which has accrued 
is accessed from the differences between databases DB12 
and DB13 and the Assets generated by the exposure of the 
allocated repayments is shown as "Index Repaid". The 
Redemption Penalty is of course dependent on the product 
type, as already described, and is accessed from database 
3 so that the final Redemption Amount is displayed on the 
basis of the above figures. As can be seen, the screen 
has personal details accessed from database 1 and in the 
present embodiment, outside the window 110 there is 
clearly displayed the transactions which have occurred 
since the initiation of the mortgage or loan. 

In order to give a clearer understanding of the operation 
of the computer system that has just been described there 
will now be given a worked example of the most basic 
steps of handling a Liability linked to a Price Index. 

The nominal term of the mortgage will be 25 years, the 
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amount £100,000 which is subject to a variable interest 
rate of 5.85%. The example given is for the type of an 
Index Repayment Mortgage in which the monthly payment is 
the sum of an Index Amount plus the interest cost. As 
with a standard repayment mortgage, in the present 
example the quoted interest rate is divided by 12 which 
is the rate the monthly payments are based on. Thus the 
first month's interest cost is 0.4875% multiplied by 
£100,000 = £487.50. Under this type of Index Mortgage 
no part of the Regular Monthly Payment is used to repay 
capital and thus the interest cost will not change unless 
there is a further Borrowing or an ad hoc Repaid 
Borrowing or there is an interest rate change. 

The Index Amount is initially determined by setting an 
amount which, if accumulated at an assumed Price Index 
growth rate, will achieve a set target value at a set 
future date. After this initial determination the Review 
process, and Review basis, will set the future level of 
the Index Amount. 

As accumulating £80.66 monthly in arrears for twenty-five 
years at: an assumed future Price Index growth rate of 
0.80% per month produces a value of £100,000 after 
twenty-five years this might be used as the Index Amount 
initially assuming it accords with the Review basis. 
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Upon the above basis, and for this particular type of 
Index Mortgage, the monthly payment is £568.16. For a 
standard repayment mortgage with the same interest rate 
a sample calculation shows that for a 25 year term with 
unchanged interest rates a monthly payment of £635.16 is 
required. However there is no reason why a borrower might 
not wish to make higher payments and, in order to make 
direct comparisons with a standard repayment mortgage 
assume the Index Amount is set instead to £147.66 so that 
both mortgages have the same monthly payment of £635.16.. 
This is equivalent to assuming future Price Index growth 
of .0.49% jper month, rather than the previous level of 
0.8%. 



Month 1 

The borrower payment of £635.16 would be split as 
follows : 

Interest £487.50 

Repayment of principal ENil 

Index Amount £147.66 
The lender will also, set aside the following additional 
amount to assets in order to match the Index Amount 
liability: 

Assets £147.66 



Month 2 

Assuming no changes to the payment bases the borrower 
payment of £635.16 would again be split as: 
Interest £487.50 
Repayment of principal £Nil 
Index Amount £14 7.66 < 

The lender will algo set aside the following additional 
amount to assets in order to match the Index Amount 
liability; 

Assets £147.66 

Ignoring any Redemption Penalties or Outstanding Interest 
the Redemption Amount on a standard repayment mortgage 
after two months would be: 

£100,000 less £147.66 less £148.38 = £99,703.96. 
Add to this the total payments made of £1,270.32 the 
total mortgage cost would have been £100,974.28. 

Ignoring any Redemption Penalties or Outstanding Interest 
the Redemption Amount for the Index Mortgage after two 
months would be £100,000 less the current value of 
£147.66 paid after month 1 less the value of £147.66 just 
paid. Clearly the latter Index Amount will have had no 
Price Index Exposure so the Redemption Amount would be: 



£100,000 less £147-66 less £147.66 x Price Index 
movement . 

Add to this the total payments of £1,270.32 the total 
mortgage cost would have been £101,122.66 less £147.66 
x Price Index movement. 

* 

If the Price Index movement over the one-month is equal' 
to the mortgage interest rate the Redemption Amount and 
total mortgage cost would be £99,703.96 and £100,974.28 
respectively - in other words exactly the same as the 
standard repayment mortgage. 

If the Price Index movement over the one-month was equal 
instead to an amount that exceeded the monthly interest 
rate then the Redemption Amount and total mortgage cost 
would both be less than under a standard repayment 
mortgage . 

Setting up the System 

Using the above example, the system operates in the 
following manner. 

It will be appreciated that a User can set up all 
databases from scratch each time. In practice though the 
User will access a product code and this will accord with 
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a particular Index Mortgage product description and will 
automatically populate a number of databases. In the 
present embodiment this is databases 083,5,6,8,9,16,18,19 
and 20. * 

5 

On this basis the User would be left to populate 
databases DB1 and 2, for example by hand via a keyboard 
or electronically by keyboard activation to transfer data 
from one or more databases on a pre-mortgage completion 
10 system. 



The current interest rate (0,4875%) is held in database 
DB4. This database is not specific to any particular 
Liability and will be updated by some general form of 
database management and updating. Naturally database DB4 
can hold a range of interest rates applicable to 
different Liabilities and borrowers. 



15 



20 



25 



The User will input the initial Borrowing of £100,000 
into database DB10. 

Ongoing Popula tion of Databases 

All databases above may receive additional or change data 
input by the User. Some form of general database 
management and updating will update database DB7, as it 
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is not Liability specific. As can be seen in Figure 6 
Database DB7 basically holds details of every Price Index 
which can be used including the price of ^ each index at 
every relevant date. 

Databases 0611,12,13,14,15 anil 17 will be, populated with 
the results of the system routines which will hereinafter 
be* described with relation to the worked example just 
given . 

It will also be appreciated that there are a variety of 
ways that the system can be set up to start its routine 
following the start of a new mortgage (or loan). For 
example all routines might be run on an overnight ' batch 
run. Others might be scheduled to run every hour, for 
example. The assumed first Routine Run/Batch Run date 
is D/M/Y. 

Assume the start date of a mortgage with reference Al is 
D/M/Y and that there is immediate activation of a 
schedule of routines following the User notifying the 
system that a new mortgage has been successfully set up 
on the system. 



For illustrative purpose the description below 



goes 



through all routines even though in practice the system 
would be scheduled only to run the definitely required 
routines. This is because such scheduling would be User 
defined and subject to wide variation according to 
various factors . 

4 

Routine One * * 

Collect and sum all Borrowing transactions from database 
DB10 for mortgage reference Al up to D/M/Y 
Result 1: £100 , 000 

Collect and sum all transactions from DB14 of Capital 
type (a Repaid Borrowing reference) f6r mortgage 
reference Al up to D/M/Y 

Result 2: £Nil (the way the data is held this field will 
be negative) 

Calculate result 1 plus result 2 
Result 3: £100,000 

Send [Total Borrowings, result 3] and [D/M/Y] to database 
DB17 mortgage reference Al and end routine 

Routine Two 

Check DB12 for last date of Accrued Interest data for 
mortgage reference Al . As shown in Figure 6 database 
DB12 holds the mortgage reference (Al), the date and the 
amount of Accrued Interest. 
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Result 1: Null 

If result 1 = Null then send [Accrued Interest, Nil] and 
[D/M/Y] to database DB12 mortgage reference Al and end 
routine 

5 

Routine Three 1 

Check if any Payment for mortgage reference Al up to 
D/M/Y is held in database DB14 and has Payment Due 
reference. This assumes that due payments are processed 
10 with a separate reconciliation routine that allows for 

due but not paid payments. 
Result 1: Null 

If result 1 = Null then continue as below 
Check if any Positive Advance for mortgage reference Al 
15 up to D/M/Y is held in database DB14 and has Not 

Processed reference. This is on the assumption that 
Positive. Advances are "registered" on the system by a 
User and then processed by the system upon the next Batch 
run. Database DB14 is also shown in Figure 6 and 
includes the list of mortgage references. 
Result 2: Null 

If result 2 = Null then end routine 
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Routine Four 
Subroutine 1 

Set j = 1 

Sum all units from database DB15 for Price Index j 
up to date D/M/Y for mortgage reference Al 
( Result l.j: 

Result l.j.l: Nil/Null 

Result l.j. 2: Price Index j , 

Result l.j. 3: D/M/Y 
Collect Price Index price for Price Index in result 
l.j. 2 as at result l.j. 3 from database DB7 
Result 2.j: Plj (D/M/Y) 

Check if Price Index is the final Price Index, if 
not then set j = j+1 and re-run 
End subroutine 1 

Calculate the sum of {result l.j.l multiplied by result 
2.j} for all j (this is the Price Index Value) 
Result 3: £nil 

Send [Price Index Value, result 3] and [D/M/Y] to 
database DB17 mortgage reference Al and end routine 

Routine Five 

Check database DB10 for a Redemption transaction for 
D/M/Y that has a Not Processed reference for mortgage 
reference Al 



Result 1: Null 

If Result 1 = null then Collect Redemption Penalty rules 
from database DB3 and calculate the Redemption Penalty 
using D/M/Y 
Result 2: £RP 

Send [Redemption Penalty, result 2] and [D/M/Y] to 
database DB17 mortgage reference Al 

Collect (up to date D/M/Y) and sum Accrued Interest 
transactions from database DB12 for mortgage reference 
Al 

Result 3: Null 

Collect (up to date D/M/Y) and sum Paid Interest 
transactions from database DB13 for mortgage reference 
Al 

Result 4: Null 

If results 3 and 4 are both Null then send [Outstanding 
Interest, Nil] and [D/M/Y] to database DB17 mortgage 
reference Al and end routine 

Routine Six 

Calculate Total Borrowings plus Redemption Penalty plus 
Outstanding Interest less Price Index Value from database 
DB17 at D/M/Y for mortgage reference Al 
Result 1: £100,000 + £RP 

Check if result 1 is less than or equal to zero 
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Result 2: No 

If result 2 = No then end routine 

Routine Seven 
All User defined 

Routine Eight 

Collect Review Basis for mortgage reference Al . (This, 
in the present embodiment, includes the target Price 
Index Value of, currently, £100,000 at D/M/Y+25, interest 
rate of, currently 0.4875% per month, Price Index growth 
rate assumption of, currently, 0.49% per month, Net 
Liability of currently £100,000, Total Borrowings of 
currently £100,000, Price Index Value of currently £Nil 
and monthly in arrears payments), in this simplified 
example there is only one Price Index Gearing which is 
100% and the Payment allocation rules are assumed to be 
to cover interest first then allocate all the remainder 
to Index . 

Calculate the implied Regular Mortgage Payment amount due 
on D/M+l/Y (and its component parts) 
Result 1: 

Result 1.1 Total £635.16 

Result 1.2 Interest £487.50 

Result 1.3 Index Amount £147.66 
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Compare result 1 . 1 to the actual current Regular Mortgage 
Payment so first collect from DB14 for the latest date 
prior to D/M/Y for an entry for mortgage reference Al 
Result 2: Null 

If result 2 = Null then do not compare payments and send 
[Payment Due, result 1] and [D/M+l/Y] to database DB14 
mortgage reference Al and end routine 

i 

Routine Nine 

Check database DBG for any Price Index switching for 
mortgage reference Al triggered by D/M/Y 
Result 1: Null 

If result 1 = Null then end routine 
Routine Ten 

Check database DB14 at D/M/Y for a Payment Allocated for 
mortgage reference Al 
Result 1: Null 

If result 1 = Null then end routine 

Routine Eleven 
All User defined 

Assume the next Routine Run/Batch Run date is D/M+l/Y. 
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Routine Onp> 

Collect and sum all Borrowing transactions from database 
DB10 for mortgage reference Al up to D/M+l/Y 
Result 1: £100,000 * 
5 Collect and sum all transactions from DB14 of a Capital 

type (a Repaid Borrowing reference) f6r mortgage 
reference Al up to D/m+1/y 
Result 2: £Nil 4 

Calculate result 1 plus result 2 
10 Result 3: £100,000 

Send [Total Borrowings, result 3] and [D/M+l/Y] to 
database DB17 for mortgage reference Al and end routine 
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Routine Two 

Check database DB12 for last date of Accrued Interest 
data for mortgage reference Al 
Result 1: D/M/Y 

(At this point the simplest approach is to calculate 
Accrued Interest daily, thus repeating a calculation 
routine a day at a time until D/M+l/Y, but Users might 
have a variety of approaches). 
If routine Run Date > result 1 then: 
Set j = 1 

Set Date = result 1 + l day 

Calculate Total Borrowing from databases DB10 and 
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DB14 at Set Date less one day (again there are a 
variety of possible rules here) 

Collect Interest rate from database DB4 for 
(applying to) Set Date 

Calculate daily equivalent interest rate R% from 
Interest rate * 
Calculate R% x Total Borrowing 

Send [Accrued Interest, result 2.j] and [Set Date] 
to database DB12 mortgage reference Al 
Check if set Date = Routine Run Date (if it is then 
end routine else add one day to Set Date and add 1 
to j and repeat above) 

Routine Threat 

Check if any Payment for mortgage reference Al up to 
D/M+l/Y is held in database DB14 and has Payment Due 
(this note assumes that due payments are processed with 
a separate reconciliation routine that allows for due but 
not paid payments). 

Result 1: £635.16 with due date D/M+l/Y 

As result 1 is not' equal to null check if Routine Run 

date - due date from result 1 

If it does not then end routine else 

Sum Accrued Interest from database DB12 to D/M+l/Y 

for mortgage reference Al 



Result 2.1: £487,50 (assuming the interest rate and 
Total Borrowings remained unchanged during the 
period) 

Sum Paid Interest from database DB13 to D/M+l/Y for 

mortgage reference Al 

Result 2.2: £Nil 4 

Calculate result 2.1 less result 2.2 

Result 2.3: £487.50 

Check if payment amount > = result 2.3 

Result 2.4: Yes 

If result 2.4 = yes then 

Send [Paid Interest, result 2.3] and [D/M+l/Y] to 
database DB13 mortgage reference Al 
Calculate result 1 less result 2.3 
Result 3: £147.66 

Determine how to allocate result 3 between Capital 
and Index using the rules from database DB5 (in 
this case all of result 3 is allocated to Index) 

Result 4.1: Capital = £0 (note this is held as 

a negative number) 

Result 4.2: Index = £147.66 

For Index transactions collect Price 

Index links from database DB6 

Result 5.1: Price Index One 

Collect appropriate Price Index price 
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from database DB7 
Result 5.2: PI1 (D/M+l/Y) 
Divide result 4.2 by result 5.2 
Result 5.3: Units 1 

Send [Unit Transaction, result 5.3] and 
[Price Index, result 5.1] and [D/M+l/Y] 
to database DB15 mortgage reference Al 
send [Interest, result 2.3] with [D/M+l/Y], 
send [Capital, result 4.1] with [D/M+l/Y], 
send [index, result 4.2] with [D/M+l/Y] and 
send [Payment Allocated, result 1] with 
[D/M+l/Y] all to database DB14 under mortgage 
reference Al 

Check if any Positive Advance for mortgage reference Al 
up to D/M+l/Y is held in database DB14 and has Not 
Processed reference (this note assumes that Positive 
Advances are processed by the User so that they are 
"registered" on the system but not processed by the 
system until the next appropriate Batch Run) 
Result 3: £Nil 

If result 3 = Nil then End Routine 

Routine Four 
Subroutine 1 

Set j = 1 
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Sum all units from database DB15 for Price Index j 
up to date D/M+l/Y for mortgage reference Al 
Result l.j: 

Result l.j.l: Units j 

Result l.j. 2: Price Index One 

Result l.j. 3: D/M+l/Y 
Collect Price Index price for Price Index in result 
l.j. 2 as at result l.j. 3 from database DB7 
Result 2.j: Plj (D/M+l/Y) 

Check if j is final Price Index, if not then set j 
= j+1 and re-run 
End subroutine 1 

Calculate sum of result {l.j.l multiplied by result 2. j> 
for all j (this is the Price index Value) 
Result 3: £147.66 

Send [Price Index Value, result 3] and [D/M+l/Y] to 
database DB17 for mortgage reference Al and end routine 

Routine Five 

Check database DB10 for a Redemption transaction for 
D/M+l/Y that has a Not Processed reference for mortgage 
reference Al 
Result 1: Null 

If result 1 = null then Collect Redemption Penalty rules 
from database DB3 and calculate the Redemption Penalty 
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using D/M+l/Y 
Result 2: £RP 

Send [Redemption Penalty, result 2] and [D/M+l/Y] to 
database DB17 for mortgage reference Al 

Sum Accrued Interest from database DB12 to D/M+l/Y for 
mortgage reference Al, 
Result 3: £487.50 

Sum Paid Interest from database DB13 to D/M+l/Y for 

mortgage reference Al 

Result 4: £487.50 

Calculate result 3 less result 4 

Result 5: £Nil 

Send [Outstanding Interest, result 5] and [D/M+l/Y] to 
database DB17 for mortgage reference Al 
End routine 

Routine Six 

Calculate Total Borrowings plus Redemption Penalty plus 

Outstanding Interest less Price Index Value from database 

DB17 at D/M+l/Y for mortgage reference Al 

Result 1: £100,000 + £RP - £147.66 

Check if result 1 is less than or equal to zero 

Result: No 

If result is no then end routine 
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Routine Seven 
All user defined 

Routine Eight 

Collect Review Basis for mortgage reference Al (this 
would include the target Price Index Value of , currently, 
£100,000 at D/M/Y+25, interest rate of , currently 0.4875% 
per month, Price Index growth rate assumption of, 
currently, 0.49% per month, Net Liability of, currently, 
£100,000 + £RP - piv (M+l), Total Borrowings of currently 
£100,000, Price Index Value of currently £147.66 and 
monthly in arrears payments) 

In this simplified example there is only one Price Index, 
Gearing is 100%, the Payment allocation rules are assumed 
to be to cover interest first then allocate all the 
remainder to Index. 

Calculate the implied Regular Mortgage Payment amount due 
on D/M+l/Y (and its component parts) 
Result 1: 

Result 1.1 Total £635.16 

Result 1.2 Interest £487.50 

Result 1.3 Index Amount £147.66 
Compare result 1.1 to actual current Regular Mortgage 
Payment so first collect from database DB14 for the 
latest date prior to D/M+l/Y for an entry for mortgage 



reference Al 
Result 2: £635.16 

Calculate result 2 less result 1.1 
Result 3: Nil 

Check if result 3 is less than Review basis tolerance 
Result 4: Yes 

Send [Payment Due, result 2] and [D/M+2/Y] to database 
DB14 mortgage reference Al and end routine* 

Routine Nine* 

Check database DB6 for any Price Index switching for 
mortgage reference Al triggered by D/M+l/Y 
Result 1: Null 

If Result 1 equals null then end routine 
Routine Ten 

Check database DB14 at D/M+l/Y for a Payment Allocated 
for mortgage reference Al 
Result 1: £635.16 

In practice there will be a complicated set of routines 
to deal with such things as payments cleared in the bank 
account but not matched by an expectation of such by the 
system, cleared payment in bank account is less than the 
system was expecting, payment cleared early or later than 
due date etc. 
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Check Bank Account for Cleared payment = result 1 that 
has not been checked off 
Result 2: 

Result 2.1: £635.16 
5 Result 2.2: D/M+l/Y 

Check off payment in result 2 ( 
Send [Payment Cleared , result 2.1] and [result 2.2] to 
database DB14 and then end rputine 

10 Routine Eleven 

All User defined 

Having described the basic process steps it is now 
possible to define the variable factors required to be 
15 calculated by the system of Figures 1 and 2 and to define 

formulae for use in the dedicated computer system which 
has been described. 

Thus the following variables have to be defined: 

20 

t TB = Total (cumulative) Borrowings at time t 

Borrowings comprise any sums lent by the 
lender to the borrower, that are not drawn 
against the Index Repaid and thus create an 
25 interest due and capital repayment liability 
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upon the borrower, less any repayments of 
Borrowings made by the borrower to the lender 

A Borrowing, if any, made at time t by the 
lender 

A Repaid Borrowing, if any, made at time t by 
the borrower » 

interest rate % that applies to the mortgage 
so that it is the rate used in the calculation 
of interest due between the periods t-1 and t. 
For definition purposes let this rate be 
defined as an APR (standardised annual rate). 

frequency of Regular Mortgage Payment (so FP 
= 12 implies monthly, l = annual etc). For 
simplicity it has been assumed that such 
regular mortgage payments are paid in arrears, 
at the end of the period, and that all other 
Ad Hoc Payments, Borrowings and Advances are 
also only made at such times, as are any 
interest rate changes. Time t is defined as 
the time when t of these periods have fully 



elapsed. 



Regular Mortgage Payment amount due at time t 
There are a number of ways that t RMP can* be 
defined, but once values for t INT, N, FP, t G 
have been selected then for anvN year mortgage 
with a certain level of borrowings and a 
certain level of index Repaid at time t there 
is a unique solution to the Required Mortgage 
Payment so that upon such assumptions a target 
future Redemption Amount is projected to be 
met upon the target future date. it is 
possible that there is no N or the lender is 
expecting the borrower to find all or some of 
the monies needed to meet the Redemption 
Amount after N years from another source. in 
this case another method or arbitrary 
judgement on the part of the borrower and/or 
lender is used to determine the Payments that 
are required, recommended or appropriate and 
their allocation between Interest, Capital and 
Index, one possible formulaic definition, in 
order that the projected Redemption Amount 
after N years is zero is as follows: 
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t RMP = t I + t RRB + t IA 

t I = the interest cost element of the Regular 

Mortgage Payment due at time t 
tl = {[(1 + t INTp(l/FP) ]-l} x t.iTB 

the Repaid Borrowing element (if any) of the 

i 

Regular Mortgage Payment due at time t, in 
this case assumed to be zero throughout 

the Index Amount, the element of the Regular 
Mortgage Payment due at time t that is 
calculated to be necessary to be allocated to 
the Index Repaid and thus exposed to future 
(various) Price Index movements assuming no 
future Repaid Borrowings are made (in practice 
the lender, having calculated a revised Index 
Amount, may choose not to actually reflect 
this in the Regular Mortgage Payment they ask 
the borrower to make) 

t+1 IA =( t TB - t IRx((l+ t G) A (NxPP- t)])/S (H _ t , 

If it is wished to assume that future Repaid 
Borrowings are not zero then in the above 
formula t TB is adjusted accordingly. 
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t IR = Index Repaid amount at time t, the accumulated 

value of all Index Amounts paid (assuming all 
due payments have been paid) plus the 
accumulated value of all Ad Hoc Negative 
Advances paid less the accumulated value of 
all Positive Afdvances taken, all at time t 

a N - planned mortgage term (in years) 

s <N-t> = {[(1 + t G)"(N x PP - t)] - 1} / t 6 



* G = Price Index link growth rate % (applying to 

the period 1/FP) assumed by the lender at time 
t as applying on average to all the Price 
15 Indices that a borrower has selected or may 

select in the future 

PI = a Price Index 

20 pij = Price Index J 

tPIj = the level of Price Index J at time t 
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Advances comprise : 

a) Positive Advances which are any sums lent by 
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the lender to the borrower that the borrower 
elects to be drawn against (i.e. deducted 
from) the Index Repaid, less 

Negative Advances which are any sums paid by 
the borrower to the lender to increase the 
Index Repaid 'amount that, were made as all or 
part of an Ad Hoc Payment (i.e". excluding the 
effect any Regular Mortgage Payments have on 
the Index Repaid amount) 

a Positive Advance, if any, made by the lender 
to the borrower at time t 

the element of a Positive Advance made at time 
t that is exposed to Price Index J 

Ad Hoc Payment amount paid at time t by the 
borrower (this is any Payment made by the 
borrower to the lender that is not a Regular 
Mortgage Payment) 

t AHRB + t AHNA 

Ad Hoc Repaid Borrowing, the element of the Ad 
Hoc Payment paid at time t that is allocated 



to a Repaid Borrowing by the borrower 



t AHNA = Ad Hoc Negative Advance,, the element of the Ad 
Hoc Payment paid at time t that is allocated 
to a Negative Advance by the borrower 

i 

t AHNAj = the element of the Ad Hoc Negative Advance 
that is exposed to Price Index J 

t RB = t RRB + t AHRB 

t AHNA = t AHNA L + t AHNA 2 + • . . ^AHNA* where t AHNAj is that - 
part of t AHNA that is exposed to Price Index J 

t lA = t TA 1 + t lA 2 + t iA x where t IAj is that part of 

t IA that is exposed to Price Index J 

< m = ||{ i^J x t PI j/iPIj} + { ,-AHNAj x ^/.Mj} - { { P Aj x .PI/^I,} 
where X = the number of Price Indices 

Ignoring any Redemption Penalties or Outstanding 
Interest, the Redemption Amount at time t = t TB - t lR. 

It will be appreciated that this formula includes the 



effect of Positive Advances made by the lender to the 
borrower which are drawn against the Index Repaid. To 
exclude the effect of these advances the last term of the 
above equation for t lR is to be omitted. 

It is i possible that t lA may be determined at the 
• discretion of the lender or the" borrower and that the 
index Repayment Mortgage need not have a planned end 
date. 

It may be required to calculate the equivalent interest 
rate applying to a Repayment Mortgage that would- have 
produced the same Redemption Amount as under a particular 
Index Repayment Mortgage. 

There are a number of ways that such an equivalent 
interest rate may be defined by any User of the system, 
for example as the overall average interest rate. Taking 
this example, for any Index Repayment Mortgage and a t lR 
result at time t, one can calculate the rate of interest, 
call it t INTAD J , that for a standard repayment mortgage 
with the same Borrowings, Repaid Borrowings, Negative and 
Positive Advances, and the same Regular Mortgage Payments 
as happened under the particular Index Repayment 
Mortgage, would have produced the same Redemption Amount 
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(the amount needed to be paid by the borrower in order 
to redeem the mortgage in full at this time ignoring any 
Redemption Penalties or Outstanding Interest). 

The computer system will calculate t I NT AD J according to 
the bespoke code for that User. The first step would be 
to determine what t RA (the Redemption Amount at time t 
under a standard repayment mortgage) would be using the 
same Borrowings, Repaid Borrowings, Negative and Positive 
Advances, Regular Mortgage Payments and Interest Rate as 
for the Index Repayment Mortgage. 

t** = I [i B ~i*HRB -.RMP + .PA —jAHNA^ X JJ^l ^jINT^ (l / FP) \ 



If t RA, on the assumptions of the previous paragraph, is 
greater than ( t TB- t IR) then the Price Index links 
selected have, overall, reduced the borrower's cost of 
borrowing. To find the equivalent overall repayment 
mortgage interest rate the processor can solve the above 
equation by replacing jINT with INT and solving for INT 
so that the right hand side equals t TB - t IR. 

It will accordingly be appreciated that in order to carry 
out the above functions the computer system of Figure 1 
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will carry out the following processing steps which are 
set out in the flow diagram of Figure 5 which represents 
the main processing normally carried out daily. For 
illustrative purposes the processes have been defined for 
an Index Loan at a time t. 

Thus Figure 5 of the accompanying drawings is a flow 
diagram of the main daily operations carried out by the 
processing system of Figures 1 and 2. 

In step S10 a check is made to determine whether or not 
an initial Borrowing, further Borrowing and/or Repaid 
Borrowing require processing. Naturally if the initial 
Borrowing has just been made the other values will be 



15 zero. 
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If the answer to this step is YES database DB10 and DB17 
are updated in step Sll. step S12 follows the two 
previous steps and in this step database DB14 is checked 
to see if there are any Positive or Negative Advances 
that require processing. Again if this is the first 
processing the answer will always be NO but if the answer 
is YES databases DB14 and DB15 are updated in step S13. 
In step S14 the values of t _ x TB, t TB, ^IP, t lNT , t _ lA I, t _ 
xIA, t AHNA and t PA are collected from the appropriate 



databases and in step S15 t AI is calculated using the 
appropriate formulae and added to database DB12. t ~iIP is 
the total interest paid by time t-1 and t . x AI is the total 
Accrued Interest at time t-1. 

Step S16 represents the Payment Collection routine and 
in it a check is made if a payment has been made since 
the last processing. If £he answer is YES then t AI - 
t -iIP is deducted and allocated to database DB13 in Step 
17 and the excess allocated to the databases DB14 and 
DB15 in Step S18. Within preset tolerances t AI should 
equal t IP. ■ In step S19 all IA, Price Index prices, t IP 
and t AI are collected from the appropriate databases so 
that the system can calculate t IR and current Outstanding 
Interest in step S20. In step S20 t IR is calculated 
using the Index Amounts IA, any Positive or Negative 
Advances which have been made and the Price Index PI 
prices, and database DB17 updated with this result. 

In step S21 the system checks if the first calculated t IR 
less any Redemption Penalties is equal or greater than 
t TB + t AI - t IP as held in database DB17 and if the answer 
is YES step S22 initiates an auto redemption process. 
If the answer is NO step S23 collects t G as part of the 
already described Review process and in step S24 the 
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system calculates average historical t iNT, average 
historical t G and average historical PI price movements 
Rising values from the appropriate databases. Step S25 
continues the Review process so as to set t G and updates 
database DB8 in step S26. 

In step S27 the system calculates S H . t and its value is 
used in step S28 to calculate an initial value for t+1 iA 
and the value so generated is used to check in step S29 
if t+1 lA = t iA, within defined tolerances. if the answer 
is NO the Review process is used to set a revised t+1 iA 
and databases DB5 and DBS are updated in" step S30;- If • 
the answer to step S29 is YES or NO step S31 checks if 
t IP = t AI. if the answer to this step is NO step S32 
initiates a Review process to set a revised t+1 i which is 
stored in database DBS in step S33. Step S34 sets t+1 RMP 
using the previously calculated t+1 IA and t+1 l. 

Step S35 checks if any automatic switching of Price 
Indices is to be carried out. if a switch is required 
the appropriate databases DB6, DB9 and DB15 are updated 
for the next cycle. 

It will be appreciated that the above described system 
keeps separate the Capital Balance Outstanding and the 
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Redemption Amount. However, it is also entirely possible 
for the system described with minor changes to calculate 
the requirements of an Index Repayment Mortgage when the 
Capital Balance Outstanding is reduced by part of each 
payment made by the borrower. As in the previous 
embodiment the variables to be calqulated will now be 
de-fined. — 

t BT = Borrowings Total at time t 

Borrowings comprise any sums lent by the lender to the 
borrower, that are not drawn against the Index Bonus and 
thus, create an interest. ...due ...and capital repayment, 
liability upon the borrower, less any repayments of 
Borrowings made by the borrower to the lender from an Ad 
Hoc Payment 

t B = A Borrowing, if any, made at time t by the lender 

t AHRB = A type of Repaid Borrowing. Specifically a 
Repaid Borrowing made, if at all, by an Ad Hoc 
Payment at time t by the borrower 



tBT = 



t ,B- AHRB 
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t TB = Total Borrowings, this is the amount upon 

which interest accrues 

x 

t TB = t BT - t TC 

t TC is the cumulative total of all Capital elements of 
Regular Mortgage Payments "made up to and including time 
t. The Capital element of a Regular Mortgage Payment is 
a type of Repaid Borrowing. 

t lNT = interest rate % that applies to the mortgage so 
that it is the rate used in the calculation of interest 
due between the periods t-1 and t. For definition 
purposes let this rate be defined as an APR (standardised 
annual rate) . 

FP = frequency of Regular Mortgage Payment (so FP = 12 
implies monthly, 1 = annual etc). For simplicity it has 
been assumed that all such regular mortgage payments are 
paid in arrears, at the end of the period, and that all 
other Ad Hoc Payments, Borrowings and Advances are also 
only made at such times, as are any interest rate 
changes. Time t is defined as the time when t of these 
periods have fully elapsed 
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t RMP = Regular Mortgage Payment amount due at time t 

There are a number of ways that t RMP can be defined, but 
once values for t INT, N, FP, and t G have been selected 
then for an N year mortgage with a certain level of 
borrowings and a certain level of Index Bonus at time t 
there is a unique solution to the required Regular 
Mortgage Payment so^that upon such assumptions a target 
future Redemption Amount is projected to be met upon the 
target future date. 

Assume that the target Redemption Amount is zero .after 
N years 



t RMP = {[( i + iINT )a(i/fp)-i]} x { i _ i bt}+ ,IA * 

Having determined the total amount of the Regular 
Mortgage Payment at time t, it is subdivided into 
t Interest and t Capital elements (that are quite different 
from the two elements upon which it has been calculated) 
at time t as follows : 



interest = {[(l + JNT) a (l / FP)]- 1 } x {^TB } 
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tCapital = t RMP - t lnterest 

t IA = the Index Amount, the amount that will be exposed 
to future Price index movements and used in the 
calculations of Index Repaid and index Bonus . Even though 
it is used to calculate t RMP, it is not part of the 
Regular Mortgage Payment : 

» 

t+1 IA = ( t BT - t IR x [ (1 + tG ) ~ ( N x FP - t ) ] ) / S(M _ t) 



t IR = Index Repaid amount at time t, this is used only 
in the calculation of t+1 iA and is the accumulated value., 
of all index Amounts plus the accumulated value of all 
Ad Hoc Negative Advances paid less the accumulated value 
15 of all Positive Advances taken, all at time t 

N = planned mortgage term (in years) 

s <w-t) = { [ (1 + t G ) * (N x FP - t) ] - 1 } / t G 



tG = Price Index link growth rate % (applying to the 
period 1/FP) assumed by the lender at time t as applying 
on average to all the Price Indices that a borrower has 
selected or may select in the future 



25 
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PI = a Price Index 



10 



15 



PIj = Price Index J 



t PIj = the level of Price Index J at time t 

Advances comprise: 

a) Positive Advances, which are^ any sums lent by 
the lender to the borrower that the borrower 
elects to be drawn against (i.e. deducted 
from) the Index Bonus, less 

b) Negative Advances, which are any sums paid by 
the borrower to the lender to increase the 
Index Bonus amount, that were made as all or 
part of an Ad Hoc Payment (i.e. excluding the 
effect any Regular Mortgage Payments have on 
the Index Bonus amount) 



20 tPA = 



a Positive Advance, if any, made by the lender 
to the borrower at time t 



tPA, - the element of a Positive Advance made at time 
t that is exposed to Price Index J 



25 
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Ad Hoc Payment amount paid at time t by the 
borrower (this is any Payment made by the 
borrower to the lender that is not a Regular 
Mortgage Payment) * 

t AHRB + t NA t 

the element of the Ad Hoc Payment paid at time 
t that is allocated to a Repaid Borrowing by 
the borrower " 

Negative- Advance, the element of the Ad Hoc 
Payment paid at time t that is allocated to a 
Negative Advance by the borrower 

the element of a Negative Advance that is 
exposed to Price Index J 

t NA x + t NA 2 + ... t NA x where t NAj is that part of 
t NA that is exposed to Price Index J 

t IAl + t iA2 + ... + t lAX where t IAJ is that part of 
t IA that is exposed to Price Index J 
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tIR - Z j i MJ * tPIj I iPI j\ *\iNAjx t Pl j I iPl _/)-{/ PAj x t Plj I iPlj] 

t 

where X = the number of Price Indices 

Define t MIPI as the Mortgage Interest Price Index so that 
t MliPl = t _,MIPl x [(1 + t INT ) A (1/FP) ] 
with 0 MIPI = l 



Ignoring any Redemption Penalties or Outstanding 
Interest, the Redemption Amount at time t = t TB - £ ib 

t IB = Index bonus at time t 
t X 

tIB = £ E ^ i !A j *{t pi j n "j -t Mmj // wpi j] + {/ am j h pi j // pij] - (/ PAJ x t pij // p/j) 

Referring now to Figure 7 of the accompanying drawings 
this shows a main processor or server at 1 linked by 
appropriate lines such as a fast LAN to co-servers 2 lr 
2 2 , 2 3/ 2 ir ... 2„ and to processors 3 lr 3 2 , 3 3 , 3 4 , ...3 n . 
Naturally the provision of co-servers and additional 
processors will depend on the number of mortgages being 
administered. Associated with the main processor 1 are 
printers 4 for generating reports, letters and the like 
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together with additional back up equipment 5. 



External connections are generally indicated at 6 so that 
the system can communicate via data links 7 and 8 to 
obtain interest rates and stock market information as 
well as the banking system to process regular payments 
such as direct debits. Thus these links are basically 
utilised for obtaining data relevant to the operation of 
the system. 

The external connection may also include a connection 9 
for linking- -the system to the Internet for the purpose 
of E-mail, IMAP and Pop3 etc. 

Finally the main processor can be connected to the or 

more lender terminals 10 lr 10 2 , 10 3 10„ via any 

suitable network N such as a fast LAN network or the 
PSTN. 

It is of course possible for the fast LAN network to be 
replaced by the Internet. 

However, given the nature of the present invention 
security reasons mean that it is likely that a non-public 
network will be preferred for organisations involved in 
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the management of multiple individual Net Liability 
positions. 

It will be appreciated that there are many software 
packages which can be used in the implementation of the 
data processing system which has just been described. 
In relation to the server 1 the following software can 
be used, namely SQL Server , Exchange 2000 , Win 2000 
server, EM Batch Jobs, EM Com + Obj.Proc, EM Com Module, 
MS ADO Com Obj., MS CDO Com Obj., OLE Automation, VB Run 
Time and D Com Server. 

With regard to the processors 3 2 3 n the following 

software can be used, namely Win 2000 Pro, EM Batch Jobs, 
EM Com Module, EM Com+ Obj. Proc, MS ADO Com Obj., OLE 
Automation and VB Run Time. 

Finally with regard to the client terminals 10 1 - 10 n 
these can utilise Active X Data Objects, OLE Automation, 
MS Report Designer, EM GUI, EM Com Obj., MS ADO Com Obj. 
and VB Run Time. 

All these software packages are Registered Trade Marks. 
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GLOSSARY 

Accrued Interest 

Accrued interest is the amount of interest that has 
accrued on an Index Loan since it started and is based 
upon the index Loan interest rate and the level of Total 
Borrowings from time to time. 



Assets (Asset) 

An Asset or Assets can only be created when a Payment is 
made by the borrower of an Index Loan to the lender where 
the borrower requests that such Payment is to create an 
• exposure to the movements in one- or more Price indices 
(the Payment creates an allocation to Index). 

The value of Assets at any time is determined solely by 
the sum of amounts allocated to index after each such 
amount has had applied the relevant movement or movements 
in value of one or more Price Indices to it after ' such 
movement or movements have themselves had the appropriate 
Gearing factor applied, where the term Price Index Value 
is used it refers to the value of Assets. 

For the purposes of describing two possible product 
constructions of an Index Mortgage the terms Index Repaid 
and index Bonus are used and, in each case, these are the 



value of Assets. 



Borrowings 

The cumulative total of all capital or principal borrowed 
by the borrower from the lender to date under any one 
1 Index Loan is called Borrowings with each individual 
tranche of Index Loan borrowed called a Borrowing. Note 
that this excludes any repayments of capital - see Repaid 
Borrowings and Total Borrowings. 

Gearing 

This- is the factor that .. is .. applied to Price Index 
movements, or set of factors applied to Price Index 
movements at specified levels. In the description of two 
possible product constructions of an Index Mortgage the 
Price Index levels are assumed to be after the Gearing 
factor or factors have been applied. 

Index 

This is the amount that is to be exposed to future 
movements of one or more Price Indices; such amount is 
created by the making of a Payment but does not 
necessarily comprise part of the Payment. 

For the purposes of describing two specific Index 



Mortgage product constructions the terms Index Amount (in 
relation to Regular Mortgage Payments) and Negative 
Advance- (in relation to Ad Hoc Payments) are used, in 
each case these terms refer to Index. 

Index Loan 

A loan whose repayments made by the borrower to a lender 
can be linked to one or more Price Indices. 

Index Mortgage 

A specific type of index Loan where the loan is secured 
and specifically secured against- specif ic property ,~ land - 
or building. Index Repayment Mortgage is the same as 
Index Mortgage. 



Index Repaid and Index Bonus 

The terms Index Repaid and Index Bonus are both the value 
of Assets, but in each case relating to a specific 
product construction of an Index Mortgage and, in 
particular, a specific construction of both exposure to 
Price Indices and amount of a Regular Mortgage Payment 
that is allocated as Index (and hence exposed to future 
Price Index movements ) . 



10 
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Liabilities (Liability) 

A Liability or Liabilities can only be created by the 
existence of an Index Loan and comprise the amount needed 
at any time in order to repay or redeem the Index Loan 
(if the effect of Assets is excluded). 

The value of Liabilities at any time comprises • the -• - 
current Total Borrowings plus any Outstanding Interest 
plus any Redemption Penalties. 



Net Assets 

This- is the- absolute value of Assets less the absolute 
value of Liabilities. 



Net Liabilities 

This is the absolute value of Liabilities less the 
absolute value of Assets. 



Net Position 

This is either Net Assets or Net Liabilities. 
Outstanding Interest 

Outstanding Interest is simply Accrued Interest less Paid 
Interest. 
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Paid Interest 

Paid Interest is the amount of Payments made by the 
borrower to the lender that have been allocated towards 
the payment of interest. It is assumed that Paid 
Interest can never exceed Accrued Interest. 

Payments 

These are amounts paid by the borrower to the lender 
under an index Loan and can either be made on a regular 
basis and/or one off. Regular payments under an Index 
Mortgage are called Regular Mortgage Payments and one off 
• payments made under an Index Mortgage are called Ad- Hoc 
Payments . 

Payments must be allocated to a combination of up to 
three elements: Interest, Capital (this is a Repaid 
Borrowing) and Index. 

Positive Advance 

This is a payment from the lender to the borrower but is 
not a Borrowing, instead the value of Assets is reduced 
by the amount of the payment. Alternatively the borrower 
may request that a payment is instead allocated as a 
Repaid Borrowing, thus reducing Liabilities. 
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Price Index (and Price Indices) 

An index of prices where such prices are the price of a 
commodity, share or any other type of asset or any index 
of prices, or derivative on, such assets, or a 
combination' thereof. More than one Price Index is 
referred to as Price Indices. , 

Price Index Value 

The current value of Assets. 

Redemption Penalties 

• These- are the penalties, if any, that may apply upon any 
Repaid Borrowing from time to time. 

Repaid Borrowings 

The cumulative total of all capital (or principal) repaid 
to the lender by the borrower to date under any one Index 
Loan is called Repaid Borrowings (with each individual 
repayment called a Repaid Borrowing) . 

Note that a borrower may request that the value of Assets 
relating to his Index Loan is reduced by some amount and 
that this amount be applied as a Repaid Borrowing 
although this does not affect the Net Position. 
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Review 



This is a process under which the level of Payments being 
made by the borrower is- compared to any Net Position 
level objective at some future date, the result of which 
may be to recommend or require a borrower to alter his 
Planned level of future Payments, or adjust intended 
future Payment dates, or adjust Price Index links 
applying to t^e current Assets or adjust the Price index 
links intended to apply to future Index allocations, or 
any combination thereof. Although a Review is not a 
mandatory requirement of operating an Index Loan it is 
difficult to see why in practice a lender would not carry - 
them out from time to time. 



15 Review Basis 

This is the set of data and assumptions used in order to 
carry out a Review. Such data and assumptions include 
a future Net Position target level, a date that such 
target level applies at, the current value of Assets, the 
current Total Borrowings, current Outstanding Interest, 
future Redemption Penalties, future Payment' amounts, 
their frequency and Index allocations , Gearing and future 
Price Index growth rates. 
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Total Borrowings 

Total Borrowings at any time is the cumulative total of 
all capital (or principal) borrowed by the borrower from 
the lender to date under any one Index Loan less the 
cumulative total of all repayments of capital (or 
principal). This is Borrowings less Repaid Borrowings. 
An example of a standard repayment mortgage is given and 
,the term Capital Balance Outstanding is used, this is 
Total Borrowings. 

Note that a borrower may request that the value of Assets 
relating to his Index Loan is reduced by some amount and 
that this amount be paid by the lender to the borrower, 
this does affect the Net Position, but does not affect 
Borrowings or Total Borrowings. 

For the purposes of describing two possible constructions 
of an Index Mortgage the term Positive Advance is used 
and this refers to this case where the borrower requests 
that the value of Assets be reduced and the amount be 
paid by the lender to the borrower. 



* 
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CLAIMS : 
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1. Data-processing apparatus for the management of a 
plurality of different loans comprising: 

means defining a database* structure having 

a first plurality of fields adapted for storing 
identification data defining borrowers; 

a second plurality of fields adapted for storing 
'financial "data defining loan amounts and asset 
amounts ; and 

a third plurality of fields adapted for storing 
parameter values which define loan management 
operations so as to permit different loans to be 
managed in accordance with different management 
operations as defined by different stored, said 
parameter values, at least one of said third 
plurality of fields being adapted to store a 
variable index value for use in making adjustments 
to one or more of said asset amounts; 

means defining a plurality of graphical user interfaces 
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enabling an operator to enter at least some of said 
parameter values into said third plurality of fields and 
to associate different said parameter values with 
different loans; and 

processing * means operable for performing management 
functions on said loans in accordance with the parameter 
values associated with the respective different loans. 

2. Data-processing apparatus having stored therein a 
computer , program for managing a plurality of different 
loans, said program comprising: 

means for storing identification data for a plurality of 
borrowers ; 

means for storing data defining liabilities relating to 
loans made to respective said borrowers; 

means for storing data defining assets relating to 
respective said borrowers; 

means for storing at least one variable index value for 
use in adjusting the value of at least some of said 
assets ; 
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means for recording payments made by respective different 
borrowers relating to said assets and said 1 liabilities 
of the respective borrower; 

means for the performance of data processing functions 
relating 1;o said payments, said assets, said index values 
and said liabilities for respective different said loans; 

control means for storing a plurality of parameters which 
define the operations which take place during the 
performance of said data processing functions; and 

user interface means for enabling a user to enter 
selected values for said parameters and to associate said 
selected values with the respective said loans so that 
the data processing functions performed in relation to 
different said loans may comprise respective different 
operations in dependence upon the selected values of said 
parameters . 

3. Apparatus according to claim 2 wherein said 
parameters define the allocation of an incoming payment 
between repayment of capital, payment of interest and 
generating an asset. 



99 

4. Apparatus according to claim 2 or claim 3 and adapted 
to generate an alert when the value of liabilities and 
the value of assets are substantially equal. 

5. A computer system for managing Net Position , Assets 
and Liabilities , the system comprising: 

memory means and digital processor means, ^herein said 
memory unit includes: 

a plurality of control programs defining routines to be 
carried out by the digital -processing means; 

a liability file having a plurality of storage areas for 
storing the amounts of a plurality of Liabilities in 
response to user input; 

a liability interest rate file having a plurality of 
areas for storing in response to user input interest 
rates applicable to said Liabilities; 

an accrued interest file having a plurality of storage 
areas for storing data relating to the amounts of 
interest accrued on each of said Liabilities; 



a paid interest file having a plurality of storage areas 
for storing data relating to amounts and dates of any 
interest paid in respect of individual ones of said 
Liabilities; 

a payment file having a plurality of storage areas for 
storing data relating to payments made that create 
exposure to a Price Index so as to generate Assets, each 
payment being related to one of said Liabilities; 

a Price Index file having a plurality of storage areas 
for storing in response to user input data identifying 
at least one Price Index; 

a Price Index exposure file having a plurality of storage 
areas for storing user input data defining the degree of 
exposure of a payment associated with a particular 
Liability to a selected Price Index or to Selected Price 
Indices; 

a Price Index price file having a plurality of storage 
areas for storing in response to user input the data 
relating to the historic prices of the or each one of 
said Price Indices stored in said Price Index file; 



a Price Index transactions file having a plurality of 
storage areas for storing data relating to the amount of 
transactions that create or reduce exposure to any Price 
Index and the date of the transaction, where such 
transactions are in respect of a particular one of said 
Liabilities; and « 

wherein the digital processing means is adapted to 
calculate the total amount of each Liability from data 
stored in said liability file; 

to calculate accrued interest' for each Liability from 
data stored in said accrued interest file; 

to calculate the value of transactions linked to a Price 
Index and associated with a Liability in response to data 
stored in said Price Index price file and said Price 
Index transactions file; 

to calculate for each Liability the actual Net Liability 
from data stored in said liability file f said accrued 
interest file, said paid interest file, said payment 
file, said Price Index price file and said Price Index 
transaction file; 



to read in response to an output command entered through 
said input unit, data generated by said fourth processor 
means ; and 

to generate in response to an output command display data 
representing the Net Position of a selected Liability and 
its associated Assets. 

* 

6. A system according to claim 5, wherein said digital 
processing means is adapted in response to a control 
program to calculate from the data in the first database 
the amount t lR of the Liability deemed to have been 
repaid at a time t as a result of amounts allocated as 
Index, and the resulting exposure to one or more Price 
Indices, from payments made by the borrower in accordance 
with the formula 

* IR - Z Z \ IA x PI ./.PI } + { .AHNA.x PIJ.Pl] 
i = iy = \{ l J t J 1 J) [i J t J i j\ 

where ilA-j, = the amount of a payment made at time i 

which has been linked to a Price Index j ; 

iAHNAj = the element of an Ad Hoc Negative Advance made 

at time i that has been exposed to Price Index j ; 

iPIj = the price of Price Index j at time i; 



X = the total number of Price Indices. 



7. A system according to any one of claims 5 and 6, 
wherein said digital processing means is adapted in 
response to a control program to calculate from the data 
in the first database the amount t IR of the Liability 
deemed to have been repaid at a time t as a result of 
amounts allocated as Index, and the resulting exposure 
to one or more Price Indices, from payments made by the 
borrower in accordance with the formula 

t iR = ■ {■ £ J M pi jjpj \ + \ahna.xpi./.pi\ - • 

i= lj= il< J 1 J 1 J) 1* J t j i j) 

where iIAj, = the amount of a payment made at time i 

which has been linked to a Price Index j; 

iAHNA-j = the element of an Ad Hoc Negative Advance made 

at time i that has been exposed to Price Index j ; 

iPIj = the price of Price Index j at time i; 

X = the total number of Price Indices. 

8. A system according to any one of claims 5 to 7 and 
comprising a Review Basis file having a plurality of 
storage areas for storing in response to user input data 



i 
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representing a numerical value ( t G) representing an 
assumed growth rate of said Price Index associated with 
one or more particular liabilities; and 

wherein said digital processor means is adapted to 
calculate in response to a control program regular 
payments ( t RMP) due from the borrower of a particular 
Liability* potentially sufficient over a period of the 
Index Loan to repay the interest due and the capital 
balance by calculating for selected amounts of selected 
ones of said regular payments made by a borrower an 
accumulation factor for the selected amounts derived from 
said numerical value. 



15 9. A system according to claim 8, wherein said digital 

processing means is adapted to, calculate for any 
particular Liability from data in said accrued interest 
file, said paid interest file, said payment file, said 
Price index file, said Price Index transaction file and 

20 said Review Basis file, a projected future Net Position 

for said particular Liability on the basis of both the 
actual variations in the Price Index or Price indices to 
which the payment stored in said payment file is linked, 
and on the basis of the assumption of Price Index 
25 behaviour stored in said Review Basis file. 
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10. A system according to claim 8, wherein said digital 
processing means is adapted to calculate in response to 
a control program from data comprising t INT, the 
interest rate that applies to the Index Loan, for period 
t-1 and t, some period N, the frequency (FP) of regular 
payments and an Index 'Amount ( t IA), which is the portion 
of the ( t RMP) to be exposed to the Price Index (PI) and 
the future growth rate of the Price Index assumed at time 
t, which growth rate is given by ( t G).a projected future 
value of Assets. 

11. A system according to one of claims 5 to 10, wherein 
said digital processing means is adapted in response to 
a control command to calculate a t G potentially different 
from t _ x G from the history of prices of the Price Index 
stored in said Price Index price file and the history of 
stored interest rates stored in said liability interest 
file. 

12. A system according to any one of claims 8 to 11 , and 
wherein said digital processing means is adapted to 
calculate in response to a control command at a selected 
time t during the period N the current value of t+1 lA and 
to compare the actual growth rate of the Price Index with 
the assumed growth rate ( t G) and to compare t IR with the 
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planned value of the same so as to generate data 
indicating whether or not a change has to be made to t G 
for the subsequent period of the Loan, and to recalculate 
a new value of t +iIA. 

13. A system according to claim. 11 or 12, wherein said 
digital processing means is adapted to calculate at time 
t in response to a control program the Index Amount t+1 iA 
representing the element of t+1 RMP due at time t+1 to be 
exposed to the movement of the Price Index (PI) in 
accordance with the equation 

l+l U=( t TB- t IRx[(l+ t G)\NxFP-t )])/S CN _ 0 

where t G = Price Index growth rate during one FP period 
assumed at time t to apply for each such period from t 
to N for some value of N, and s (N _ t) is an accumulation 
factor. 

14. A system according to claim 13, wherein said digital 
processing means is adapted to calculate the accumulation 
factor S (N _ t) in accordance with the equation 



•Vo={[( l+ t G)*(NxFP-t) ]-l}/,G 
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15. A system according to any one of claims 5 to 14, 
wherein digital processing means is adapted to calculate 
in response to a ^control program the interest cost 
element ( t I) of t RMP due at time t in accordance with the 
equation 



= {[(i+ /+1 /?vr) A (i/FP)]-i}x / r5, 



where 



t TB=X .B- \RB 

t TB = Total Borrowings (cumulative) at time t, 

t B = a Borrowing made at time t by the Lender , and 

t RB = a Repaid Borrowing made at time t by the Borrower. 

16. A system according to any one of claims 5 to 15, 
wherein said digital processing means is adapted to 
calculate in response to a control command 



^ = /5 { [i B -i AHRB -iRMP + tPA-iAHNAjxl jj^l +jINTl (l / FP) 
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where AHRB represents an Ad Hoc Payment allocated to a 
Repaid Borrowing Jay the borrower, and 

AHNA represents an Ad Hoc Negative Payment allocated to 
t 

a Negative Advance by the borrower. 

17. A system according to any one of claims 5 to }6, 
wherein said digital processing means is adapted to 
calculate in response to a control command 



t-l 

f RA = £ 
1 2 i=0 



[iB-AHRB-iRMP + tPA-jAHNA^X 



AA 1 v^j ("«*) 



where jlNT 2 = INT 2 for all j, and to solve for the value 
of INT 2 that would cause t RA 2 to equal t TB - t IR. 

18. A system according to any one of the preceding 
claims 5 to 17, where said digital processing means is 
adapted in response to a control command to compare t TB 
plus Outstanding Interest to t IR and to generate an alert 
to cause the Index Loan to be redeemed when t IR is 
greater than or equal to t TB plus Outstanding Interest 
and any applicable redemption penalties. 
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19- A system according to any one of claims 5 to 18 , 
wherein said accrued interest file is for storing present 
interest rates applicable to said Liabilities. 

20. A system according to claim 19, wherein said accrued 
interest file is for storing present and past interest 
rates applicable to said Liabilities. 

21. A system according to any one of claims 5 to 2 0 and 
comprising an Assets database having a plurality of 
storage areas for storing data representing the Assets 
held by a lender for the' purpose of matching appropriate 
Price Index exposure , and where the digital processing 
means is adapted to sum for all Index Loans the current 
Index Repaid value for the or each Price Index. 

22. A computer system according to any one of claims 5 
to 21 including at least one remote terminal having a 
central processor,, a display device , a memory unit and 
a display unit, and wherein said remote terminal has an 
interface circuit adapted to. interface with the computer 
system whereby a command entered at the input means of 
said terminal generates a selective display on said 
display unit of the Net Position , Assets and Liabilities 
of a borrower. 
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23. A method of operating a computer system, the system 
comprising: 

* 

an input unit, a memory unit, a display unit and a 
digital processing unit to manage the Net Positions, 
Assets and Liabilities of a plurality of borrowers, 
comprising the method providing said memory unit with: 



a liability file having a plurality of storage areas for 
storing the amounts of a plurality of Liabilities in 
response to user input; 

a liability interest rate file having a plurality of 
areas for storing in response to user input present and, 
if different, past interest rates applicable to said 
Liabilities; 

an accrued interest file having a plurality of storage 
areas for storing data relating to the amounts of 
interest accrued on each of said Liabilities; 



a paid interest file having a plurality of storage areas 
for storing data relating to amounts and dates of any 
interest paid in respect of individual ones of said 
25 Liabilities; 



a payment file having a plurality of storage areas for 
storing data relating to payments made that create 
exposure to a Price Index, each payment being related to 
one of said Liabilities; 

a Price Index file having a plurality of storage ireas 
for storing in response to user input data identifying 
at least one Price Index; 

a Price Index exposure file having a plurality of storage 
areas for storing user input data defining the degree of 
exposure of a payment associated with a particular 
Liability to a selected Price Index or to selected Price 
Indices; 

a Price Index price file having a plurality of storage 
areas for storing in response to user input the data 
relating to the historic prices of the or each one of 
said Price Indices stored in said Price Index file; 

a Price Index transactions file having a plurality of 
storage areas for storing data relating to the amount of 
transactions that create or reduce exposure to any Price 
Index where such transactions are in respect of a 
particular one of said Liabilities, the date of the 
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transaction; and 



comprising utilising said digital processing means to 
calculate the total amount of each Liability from data 
5 stored in said liability file; 

to calculate the value of transactions linked to a Price 
Index and associated with a Liability in response to data 
stored in said Price Index price file and said Price 
10 Index transactions file; 



to calculate for each liability data representing the 
actual Net Liability from data stored in said liability 
file, said accrued interest file, said paid interest 
file, said payment file, said Price Index file and said 
Price Index transaction file; 



to read in response to a command entered through said 
input unit the data representing the Net Liability of the 
2 0 borrower ; and 

to generate in response to an output command a display 
of the Net Liability situation of a selected Liability 
and its associated Assets . 

25 
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24. A method according to claim 23 and wherein the 
system comprises a Review Basis file having a plurality 
of storage areas for storing in response to user input 
data representing a numerical value ( t G) based on the 
predicted future performance of the or each of said Price 
Indices , comprising calculating in Response to a control 
program regular payments ( t RMP) due from the borrower of 
a particular Liability potentially sufficient over a 
period of the Index Loan to repay the interest due and 
the capital balance by calculating for selected amounts 
of selected ones of said regular payments made by a 
borrower an accumulation factor for the selected amounts 
derived from said stored numerical value ( t G) of the or 
each one of the Price Indices (Pij) associated with said 
particular Liability. 



25. A method according to either of claims 23 to 24 , 
comprising calculating from the data in the first 
database the amount t IR of the Liability deemed to have 
been repaid at a time t as a result of amounts allocated 
as Index, and the resulting exposure to one or more Price 
Indices , from payments made by the borrower in accordance 
with the formula 

tIR = ^ £ {^A x PI JJ>l\A AHNA.x PIJ.PI } 



where iIA jf = the amount of a payment made at time i 

n 

which has been linked to a Price Index j; 

jAHNAj = the element of an Ad Hoc Negative Advance made 

at time i that has been exposed t!b Price Index j; 

iPIj = the price of Price index j at time i; 

K 

X = the total number of Price Indices. 

26. A method according to any one of claims 23, 24 or 
25, comprising calculating for any particular Liability 
from data in said accrued interest file, said paid 
interest file, said payment file, said Price Index file, 
said Price Index transaction file and said Review Basis 
file, a projected future Net Position for said particular 
Liability on the basis of both the actual variations in 
the Price Index or Price Indices to which the payment 
stored in said payment file is linked, and on the basis 
of the assumption of Price Index behaviour stored in said 
Review Basis file. 

27. A method according to claim 26, comprising 
calculating 
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' IR - tU ,Ll ' X ' PI ^' PI '} + [< AH ^ A j x .PIjIfl^-lPAjX Wfl, 

where iPAj = a positive advance made at time i which is 
exposed to the Price Index j . 

4 

28. A method according to claim 27, comprising 
calculating in response to a control program from data 
comprising t INT, the interest rate that applies to the 
Index Loan, for period t-1 and t, some period N, the 
frequency (FP) of regular payments and an Index Amount 
( t IA) which is the portion of the ( t RMP ) to be exposed- to . 
the Price Index (PI) and the future growth rate of the 
Price Index assumed at time t, which growth rate is given 
b y (tG)j a projected future value of Assets* 

29- A method according to any one of claims 23 to 28, 
comprising calculating a t G potentially different from 
t . a G from the history of prices of the Price Index stored 
in said Price Index price file and the history of stored 
interest rates stored in said liability interest file. 

30. A method according to claim 29 , comprising 
calculating in response to a control command at a 
selected time t during the period N the current value of 
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t+1 IA and comparing the actual growth rate of the Price 
Index with the assumed growth rate < t G) and to comparing 
t IR with the planned value of the same so as to generate 
data indicating whether or not a change has to be made 
to t G for the subsequent period of the Loan, and 
recalculating a neV value of t+i IA. 

31. A method according to claim 29 or 30, calculating 
at time t in response to a control program the Index 
Amount t+1 iA representing the "element of t+1 RMP due at time 
t+1 to be exposed to the movement of the Price index (Pi) 
in accordance with the equation 

M IA = ( lT B- JRx[(l + ,Gy(NxFP-t )])/S c „_ t , 

where t G = Price Index growth rate during one FP period 
assumed at time t to apply for each such period from t 
to N for some value of N, and S (H _ t) is an accumulation 
factor . 

32. A method according to claim 30, comprising 
calculating the accumulation factor S (N . t) in accordance 
with the equation 

■V„ = {[( l+,G)*(NxFP-t) }-\}/,G 
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33. A method according to any one of claims 23 to 32, 
comprising calculating in response to a control program 
the interest cost element ( t l) of t RMP due at time t in 
accordance with the equation 

z+i'-fO+z + iH*^)]-'}*^ 

i 

where 

,TB = 't ,B- ,RB 



10 t TB = Total Borrowings (cumulative) at time t, 

t B = a Borrowing made at time t by the Lender, and 

t RB = a Repaid Borrowing made at time t by the Borrower. 

15 

34. A method according to any one of claims 23 to 33, 
wherein comprising calculating in response to a control 
command 
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where AHRB represents an Ad Hoc Payment allocated to a 
Repaid Borrowing by the borrower, and 



AHNA represents an Ad Hoc Negative Payment allocated to 
a Negative Advance by the borrower. 



10 



35. A method according to any one of claims 23 to 34 
wherein said fourth processor means is adapted to 
calculate in response to a control command 



t-l 

,RA =1 
1 2 /=0 



[iB-iAHRB-iMP + fPA-jAHNdh R (l + JNt) (l/Fp) 

/*=/+! \ J 2 J 



15 



20 



where 3 INT 2 = INT 2 for all j, and to solve for the value 
of INT 2 that would cause t RA 2 to equal t TB - t iR. 

36. A method according to any one of claims 23 to 35, 
where said fourth processor means is adapted in response 
to a control command to compare t TB plus Outstanding 
Interest to t IR and to generate an alert to cause the 
index Loan to be redeemed when t iR is greater than or 
equal to t TB plus Outstanding interest and any applicable 
redemption penalties. 
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37. A method according to any one of claims 23 to 36 
wherein the system comprises an Assets database having 
a plurality of storage areas for storing data 
representing the Assets held by a lender for the purpose 
of matching appropriate Price Index exposure, and 
including in response to a control command summing for 
all Index Loans the current Index Repaid value for the 
or each Price Index. 

4 

38. Data-processing apparatus for the management of a 
plurality of loans comprising: 

means defining a database structure having 

a first plurality of fields adapted for storing 
identification data defining borrowers; 

a second plurality of fields adapted for storing 
financial data defining loan amounts and asset 
amounts ; and 

a third plurality of fields adapted for storing 
parameter values which define loan management 
operations so as to permit different loans to be 
managed in accordance with different management 
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5 
i 



operations as defined by different stored said 
parameter values, at least one of said third 
plurality of fields being adapted to store a 
variable index value for use in making adjustments 
to one or more of said asset amounts; 

means for entering different sets of said parameter 
values into said third plurality of fields f and to 
associate respective said different sets with respective 
different loans thereby to provide a plurality of 
different loan arrangements; and 



processing means operable for performing management 
functions on different loans in accordance with the 
respective different sets of parameter values. 
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ABSTRACT 
DATA PROCESSING SYSTEM 



A data-processing system for managing loans has a novel 
database structure which includes one or more fields for 
storing, in relation to one or more loans r one < or more 
variable index values which may be used for adjustment 
of the value of an a^sset or assets which may be offset 
against the amount of the loan. This makes it possible 
to* set up, in addition to simple' repayment and offset 
mortgages, more complex mortgage arrangements. For 
example, the computer system may be arranged to cause the 
value of an asset which is offset against a loan to be 
varied so as to track an external index, such as the FT- 
SE 100 index or the value of shares in a selected company 
or a particular interest rate. This tracking may be 
achieved by changing the value of the stored variable 
index value at intervals, for example daily, so that the 
stored value varies in accordance with changes in the 
external index, and causing the computer system to 
perform processing operations which vary the stored value 
of the asset on the basis of the varying stored variable 
index value. Preferably, a module is provided in the 
computer system for effecting this adjustment 
automatically by reference to external data such as the 
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FT-SE 100 index or the value of the relevant shares or 
a particular interest rate. The external data may, for 
example, be accessed via the internet. 

A novel user interface structure permits the operator to 
set parameter values which define the loan management 
operations to be performed, - such -as- the apportionment of 
repayments as between interest due, capital and the asset 
or assets to be offset against the loan. The system may 
thus be easily setup to -provide -simultaneously a wide 
range of different loan arrangements. For example, 
causing different stored variable index values to track, 
different external indices enables the offset asset 
values of different mortgages managed by the system to 
track respective different external indices and/or 
enables a single mortgage managed by the system to be 
offset against the sum of a plurality of different assets 
each tracking a different external index. 
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